Two approaches to Version Control (TFS): Need advice.

Question

Hi.

We are reaching a point in our project where we need to make a production deployment but also need to have ongoing development for future features. Our source control currently has a single development branch. In my previous company a 3 branch system was set up with Development, Integration, Production. Feature development was done in Development, tesing in Integration and Production always was the code running in the current production environment (except for a breif time when a merge was done from Integaration into Production and the deployment was done).

Each time there was a Production change or a merge into Production that was deployed live, a new archive branch was taken off Production and given a version number. Any change to a higher branch was merged back so changes in Production would make it back to Development for example. It worked but I always didn't see the need for an ongoing Integration and Production branch.

Two aspects of this system I really didn't like: 1) the merge from Integration branch into Production branch: I would prefer to have a "clean" Production branch each time even though they should be in sync after a merge and 2) this system doesn't allow for multiple deployments of the system running different versions of the code at the same time, though this has not been a requirement in either team I have worked for (yet).

I have heard this model is common but in the system I am setting up now I am proposing the following:

Have a Development branch, create a new Release branch each time Development is ready for the next deployment to production. The Release branches are given a version number and then branched again to an archive branch. Testing is done on the Release branch. Once deployed any production fixes are done in the Release branch then a new archive branch is created with a minor version number increment once deployment is approved. When a new deployment from Development is ready the a new Release branch is created...

To me this is simpler and is actually better: There is NO Integaration branch (less merging) and there is a fresh Production (Release) branch for each deployment and caters for current Production versions. What am I missing? Why go for the Development, Integration, Production model?

Thanks

Answer 1

Your proposal sounds exactly the way I am working:

• I develop in the main branch until my developments are ready
• Then a release branch is created, let's say release 1.5
• After the release branch has been tested, it is branched again, calling it 1.5.1
• Bug fixing is done in the main branch and all active release branches (e.g. 1.3, 1.4, 1.5)
• Regularly new versions (branches) of the release branches are created and sent to customers (e.g. 1.5.2, 1.5.3, ...)

In my experience this works quite good, but probably it also depends on how your company is organized.

Answer 2

Your suggestion isn't too far off the recommendations. The primary difference in the model is that you're suggesting that you develop directly on what was previously the 'integration' branch. A lot of people suggest taking a branch off this branch to do their work on, then merging back in. But it depends on the size of your team.

An invaluable resource for working with TFS branching is here:

http://tfsbranchingguideiii.codeplex.com/

Answer 3

One place I used to work had a branch for each release. We spent more time branching than we did merging. It was a bit excessive.

If you think of a mental model with a graph of connected nodes, the Production branch is just another node connected to the main Integration branch.

Answer 4

The advantage of the 3-branch system is that your developers, testers, and customers each have their own isolated version/branch of the code. This provides a "gated" development where features can only be promoted to the next branch when they pass a certain completeness/quality bar, giving high confidence that the release branch is always in a fit state to send to a customer.

Pros:

• You (almost) always have a build that could be sent to a customer at a moments notice.
• Your testers (almost) always have a working build to test
• The release branch is stable so you don't often have to fix bugs in it and reverse-merge them into the test/dev branches.

Cons:

• You have to merge frequently to promote completed features up to the release branch. This isn't too bad though, as this merge is simply a quick copy operation (as long as you don't make edits in the test/release branches, you never have a merge conflict to address)

If you take the approach of a single development branch from which you split off a release branch only when a release is required, then you are effectively working in an unbranched system most of the time. That is, you have an unstable work-in-progress build in your dev branch, which you then copy into a release branch, where you work on it as a work-in-progress until it is stabilised to release quality. If you continue developing features in the dev branch while you bugfix the release branch, you will then get a lot of merge conflicts to resolve. You spend a lot of time without a good build to test, and without a releasable build that you can ship if needed.

There also isn't really much need to branch the code into an archive branch when you release - all you need to do is label the code when you do a release to get a reliable "snapshot" of it that you can recover in future.