Version Control – Managing Source Control for Multi-Company Applications

version control

Do you find it easier to keep a branch for each company that uses software you support/develop? Each company will want "customizations" and I am just trying to figure out the best way to handle those changes. A branch for each company makes sense in the short term but I could see how this could cause issues with upgrades when a new version is developed.

Is better to have a branch for each company or to setup customizations so that they are always merged to a main branch to minimize issues with future releases?

Best Answer

Supporting a product that is customized for multiple customers is not a version control problem. It is a design and distribution problem.

Maintaining multiple code bases is a real pain. It's bad enough to need to duplicate the code base to support multiple platforms and languages, let alone multiple customers. Better instead to build a modular product. Sure, there will be elements that will require a larger degree of customization, and a small percentage of overlap where the code may need to be effectively duplicated, but it is better to create a very finely grained modular system design to cope, instead of attempting to branch where the risk is that the branches may become so divergent as to never be able to merge.

I myself work on an API that presently supports 3 hardware platforms, and greater than 3 customers. At the minimum, we would need to manage 9 separate code-bases if our code was not designed to be modular from the start. When I first arrived at the company nearly 10 years ago, the existing code base used conditional compiler directives to deal with 3 variants on a single platform, was about 50 times smaller than the present API incarnation, and took twice the effort to maintain. It took a lot of work, but we now have a product that never needs to be branched, and will be able to support literally any number of clients, platforms, and customizations.

So to specifically answer your question, It is better to maintain a single main branch provided you implement a design that will support a more modular development approach, and if your customization is required to be unavailable to more than a single customer, then you solve the problem in the way that your modules are accessed by your code, and in how they are deployed.

Related Solutions

Version Control – Creating a Version Control Strategy for SVN

If you want a unified build process, then be sure to put branches/tags/trunk at the root, like this:

branches/
tags/
trunk/
  dev/
    ...

If you don't need a unified build process, then you can put branches/tags/trunks within each project if you want. However, it might be difficult to migrate to a unified build after having put them within each project. A unified build has advantages, such as eliminating the need to publish shared components among projects -- they're all part of the build.

Personally, I like a unified build process. Furthermore, I don't think you should have a "dev" project. You should have projects directly under trunk, and then branch trunk into a dev branch. Use tags for releases. For example, I would do it like this:

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/

Version Control – Best Practices for Product Versioning and Branching in Long-Term Projects

How much (and what kind of) structure you need depends a lot on what you want to be able to do. Figure out what you can't live without, what you want to have, and what you don't care about.

A good example set of decisions might be:

Things we can't live without:

be able to reconstruct any past release at any time
be able to maintain multiple supported major versions of the product at any time

Things we would like to have:

be able to perform ongoing major-feature development (for the next major release) without worrying about branch merges
be able to perform maintenance updates to past releases

Things we can live without:

automated backporting of changes from current work to past releases
never interrupt major feature development even for a few days or a week at at time

If the above were your goals, you could then adopt a process like this:

Do all development work on the trunk of your VCS ("master" in git)
When you are close to a major release, halt major feature development, and focus on system stability for a week or so
When the trunk seems stable, create a branch for this major release
Major feature development can now proceed on the trunk, while only bug fixes and release preparation are allowed on the branch
However, all bug fixes to be made to the branch must first be tested on the trunk; this ensures that they will also be present in all future releases
Create a (VCS) tag on the branch when you are ready to release; this tag can be used to recreate the release at any time, even after further work on the same branch
Further maintenance releases to this major release (minor releases) can now be prepared on the branch; each will be tagged before release
In the mean time, major feature development geared toward the next major release can continue on the trunk
When you get close to that release, repeat the above steps, creating a new releases branch for that release. This allows you to have multiple major releases, each on their own branch, in supported status at the same time, with the ability to release separate minor releases against each.

This process won't answer all of your questions -- in particular, you will need a process in place to decide what fixes can be made to a release branch, and to ensure that bugs are not fixed on a release branch first (such fixes should always be tested on the trunk where possible). But it will give you a framework in which to make such decisions.

Best Answer

Related Solutions

Version Control – Creating a Version Control Strategy for SVN

Version Control – Best Practices for Product Versioning and Branching in Long-Term Projects

Related Topic