1

I'm sure that there is a similar question like this already in existence, but I didn't see one that matched closely enough, so here goes...

  • We use a third party company to host our site and do most of the code updates and the code is maintained in a Git repository. However, we haven't been too happy with the job they've done, so we've outsourced more and more projects to other companies.
  • These other companies maintain their own staging servers and I send them updated versions of the source code and the database as frequently as possible, but in most cases they don't always start each project with the absolute latest version of either.
  • Due to a backlog, we recently had an issue where a project that was submitted by that company didn't make it to our staging server until about a month after it had been submitted. So when these files were copied to the staging server, the file that is used by the rest of the application was about a month old and there had been quite a few updates to it in the interim.
  • So when this file went to the staging server, a lot of the recent updates were not present and functionality that had gone live on production was missing from staging. Some of the missing functionality wasn't immediately obvious because you had to be in a certain mode to notice it was missing, so it wasn't detected right away.
  • I should also mention that even before we had outside companies start working on projects, this was still a problem. Old code would frequently replace more recent updates and then we would have to pay this company to correct the problem and redo work that was already completed.

Obviously, sites that are worked on by multiple developers must face this problem on a continual basis. Is this a case where the company that controls the process employs a questionable methodology or is there really no good way to prevent this from happening? I feel like I'm stuck in a Twilight Zone version of the Springsteen song "One Step Forward, Two Steps Back".

Thanks in advance for any replies. Much appreciated!

  • 2
    If you already sending your source code to the third parties, why can't you just provide them git access(read only if need be) so that they could keep up to date themselves? – Zavior Aug 5 '16 at 0:00
2

Most version control system have a requirement that code be up to date before changes can be applied. It appears your company may be circumventing this my replacing files rather than applying patches.

If you aren't allowing access to version control, then you should be accepting patches rather than replacement files. It is not uncommon to have a secondary public(ish) repository that can be synchronized with. Approved/verified changes are then pulled into the release repository.

It appears you are using GIT, so the other companies should be pulling changes from your repository. They should be pushing releases back to you as a patch. With GIT, you need to resolve conflict before pushing changes.

Some subjects you should become familiar with:

  • Workflows for version controlling source code.
  • The standard GIT work practices.
  • Branching strategies.
  • Versioning techniques for binary data.

To prevent conflict before pushing changes, you need to pull the changes from the remote repository. (This is the up-to-date check.). Any conflicts are then local, and need to be resolved locally. Until they are resolved, you can't push your change. Other revision control systems handle this differently, but generally require you to have an up-to-date copy of the files being modified before pushing/committing changes. You can still replace files with your version, loosing any other changes that occurred since obtained. In this case, you can still find all the lost changes in the repository and prepare a patch.

I use a workflow includes updating my copy of the source frequently (daily, or at most weekly). This ensures my code incorporates any other changes. It also reduces the window for introducing conflicts.

When using revision control, source code conflicts tend to be relatively rare as changes are usually to different files, or at least different locations in the file. As a result the patch will be applied with no issues. A subset of conflicts consist of the same change being applied to the same code by two different developers. If the formatting is identical the patch will apply, skipping the already applied change.

  • How do you resolve the conflict before pushing changes if you don't even know whether you have a conflict or not until you attempt to push? – Robert Harvey Aug 5 '16 at 4:36
  • @RobertHarvey See my edit. For more detail see the GIT user manual. This gives you a good overview of how the tool should be used. Three possible workflow are shown in GIT - About - Distributed. – BillThor Aug 5 '16 at 12:32
  • 1
    Oh. Well, I always do a pull first anyway. Doesn't mean I'm a Git expert, though. Git is an elaborate Swiss Army Knife, when a simple pocket knife would do. – Robert Harvey Aug 5 '16 at 14:13
  • @RobertHarvey: your question sounds like people are trying to use it as a simple pocket knife, and finding that that doesn't do. – RemcoGerlich Aug 5 '16 at 14:15
  • It doesn't. You have to be a Git expert before you can do the simplest things in Git. Well, if you're a single user on a single branch, maybe you can use it as a pocket knife. – Robert Harvey Aug 5 '16 at 14:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.