4

We have a branching structure of:

  • multiple dev branches for each major new feature
  • Main branch, merged into from a dev branch once a feature is ready for testing
  • Release branch, merged into from Main once a feature is ready for production

We often have new features completed at around the same time that end up in Main, with some of the same source code changed. Then Feature A may be declared ready for production and need to be deployed, while Feature B requires more work.

Once changes are incorporated in Main, particularly with multiple revisions to Feature A and B, their identity as separate features is lost. It then becomes risky and difficult to promote just one of them to production. We use TFS and I don't know if this is one of its limitations.

What is the best way to resolve this? Should we be using a different branching strategy, or would a DVCS fix it?

Improve this question
2
  • What VCS are you using? – Daniel Kaplan Jan 17 '13 at 5:57
  • @Daniel TFS - it's in the question, maybe not clear enough – Alex Angas Jan 17 '13 at 7:26
4

Don't merge to main (or trunk) for testing. Trunk should always "ready-to-go" code, meaning it may not have all functionality, but will not be broken code.

Think of trunk as code you can release at any time.

Test your branches, and when they pass, merge to trunk, immediately do an integration test and then tag and deploy when ready. If the new code fails the integration, then revert, merge changes from trunk into branch and then fix the problem. Once the branch works, rinse and repeat.

You will not lose your history because you can always traverse backwards through the logs (assuming you're using something sane; CVS/VSS are not sane).

Improve this answer
3
  • Testing should take place on the feature branch surely. Reverting should be a last resort. – James Jan 17 '13 at 2:56
  • As mentioned on James' answer, how do we test several dev branches at the same time? – Alex Angas Jan 17 '13 at 3:26
  • Then how do you test that the integration with the main branch succeeds? In other words, that it does not interact with other recently merged branches? – André Jan 17 '13 at 8:37
4

You need to have someone who pushes changes from Main to each sub-branch regularly. Do the testing on the dev branches individually. Once one feature has been approved for release its changes must be merged into the other feature branches via Main. Then push to Release.

Releasing should be done on a FCFS basis unless there are dependencies.

Having different features modify the same code may result in your merge tool failing and a headache for some poor soul.

Improve this answer
2
  • I would like us to do testing on the dev branches, but we would then need to test several dev branches at the same time which still integrates all the "WIP" code together. – Alex Angas Jan 17 '13 at 3:25
  • 2
    @AlexAngas Then the problem is that your dev branches are too tightly coupled. The work needs to be divided out better. If it cannot then everyone should work from the same feature branch – James Jan 17 '13 at 15:40

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.