Our team is experiencing some growing pains with regards to source control. We use Team Foundation since it integrates so easily with our existing infrastructure, but are definitely open to other options. We deliver a software service to 15+ very different clients that require constant code updates. Right now, we have 3 branches: Development, Testing, and Production. The biggest problems we have are merging between Development -> Testing and Testing -> Production.

Our code is really a representation of business objects that are either shared between or exclusive to individual clients. Because a lot of the underlying code in our service is shared between many clients on many different versions, we constantly update our code to account for an endless list of ever-changing scenarios. Our clients will usually request a change and have that change deployed into production that week, so we have production deployments multiple times every week across clients.

We frequently encounter merge conflicts where two people made updates to the same file in either the development or test branch, and this generally causes us to need to manually merge the file into Test or from Test into Production. Unfortunately, simply enforcing check-out locks and preventing two developers from checking out and working on the same file is not an option for us because it would only create further delays and waste more time, the opposite of what we’re looking to do. We’re confident that another team has had similar issues and found a novel way to overcome this problem, and so we’d love to hear feedback on what we can do to improve our code management and development lifecycle while having minimal impact to our clients and, most importantly, our existing business process.

We are not able to operate by sprints, milestones or on a scheduled release cycle because the nature of our business requires updates to meet our clients' changing (i.e. by the day) needs. We understand that this methodology may break a lot of set rules when it comes to software engineering best practices, but most of this is mandated by the nature of our business. We’re a very successful organization, and our current method works – we just thought we should research if there are other methods for our unique model.

  • 2
    It sounds like the last paragraph was written by your boss ;) Your current method may "work" but it seems to be costing you a lot. I'm also very sceptical of your statement that changes need to be managed in the way they are. What exactly is your business? – MetaFight Feb 6 '17 at 13:45
  • 3
    (1) Having no fixed release cycle is OK, having no project management is not. (2) When you're constantly stepping on each other's toes in the code, the problem isn't your tools but team communication – devs are working independently, not as one team. I've found daily standups in front of a Kanban board super helpful to fix that. (3) Your organization may be “very successful” right now, but how are you ensuring that it stays successful? Only doing urgent but not important stuff, no proper requirements, and an architecture that can't deal with the rate of change do not sound very promising. – amon Feb 6 '17 at 14:16
  • Modern SCM are pretty good at automatically merging when the changes are on different lines, so maybe the existing "workflow" can be optimized with better tooling and/or file formatting changes? – Lucero Feb 7 '17 at 8:57
  • What is your response when a client who is 3 versions behind on a common component asks for a change on that component? Do you make the change on the old version, or do you migrate the client to the latest version(s) as part of the process? – Bart van Ingen Schenau Feb 7 '17 at 14:21

Your problem relates to how the governance should work. You should consider the decentralized approach, because the problem you describe relates to many things about the disadvantages of having centralized version control.Having decentralized version control (often called distributed version control or DVCS).

Put it simply, using DVCS means:

  • You have less worry on file locks, because each dev has their own copy of the repository.
  • You can work offline.
  • Synchronization can be done later as merge between branch after an approved Pull Requests. (but this flow might not be the best for you)

There are many best implementation of decentralized model, one the version controls that very popular are Git and Mercurial.

Based on your question, I believe you are using the original model of TFVC, Team Foundation Version Control as a centralized repository. If you use TFS, you should consider to use Git model in TFS for centralized. It is supported very nicely in TFS 2015.

This is quite overview of TFS's Git support: https://www.visualstudio.com/en-us/docs/git/overview

Deployments across client site can be simplified using deployment model in TFS release management, by leveraging Release Management of TFS using release definitions and approval gates.

First you should implement Continuous Integration (CI), then Continuous Deployment using release management implemented as release definitions in TFS.

For more info about release management in TFS 2015 (and TFS 2017), visit: https://www.visualstudio.com/en-us/docs/release/overview

| improve this answer | |

Your conflicts are caused by pushing individual changes in all 3 branches. Changing the version control system won't help you eliminate these conflicts, at best it might make it a bit easier to address them.

You seem to be operating under the assumption that what is validated and works in one branch - Dev, for example - can be safely merged into another branch - Testing in this case. Which is not necessarily true, since there were changes going into Testing which didn't go into Dev - exactly the ones causing your merge conflicts - which makes Testing diverge from Dev.

Effectively you're wasting resources attempting to stabilize 3 different environments even though you're only shipping one of them.

Switching to a true CI methodology should help you minimize the wasted efforts: have a single branch, choose a good CI system, keep everyone on the same page.

See also What is the cleanest branching strategy to use when creating reusable artifacts?

| improve this answer | |

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.