Notes on Software Design and Coding: September 2011

Wednesday, September 21, 2011

What happens if:

you and your team are working on a new set of features and the customer wants a change to his current version?
you are working on two features and the customer decides to abandon one of them?
you have two teams working on different feature sets and their changes start interfering with each other?
I just use labels instead of branches?

That’s a lot of “what if’s”, but there is a simple way of preventing this. Branching…

A key benefit of branching for development is to isolate changes from the stable Main branch. Branching adds sanity more than it adds complexity. The primary cost is the effort to do merges and resolve conflicts. A key benefit is that you have a stable code base in Main and accept changes into Main only after they pass quality gates, etc.
Branch the WHOLE “Main” line. Branch parts of your code can make integration a nightmare.
Some even go as far as to add the environments used, I prefer to think of deploying to environments (such as from Main to QA) rather than branching for QA.
Always do a Forward Integration from Main into Dev branch before you do a Reverse Integration from Dev Branch back into Main.
After branching Main to Release, we generally recommend not doing any subsequent merging (FI) from Main into the release branch.
In TFS, labels are not immutable. This does not mean they are not useful. But labels do not provide a very good development isolation mechanism. Branching allows separate code sets to evolve separately (e.g. Current with hotfixes, and vNext with new development). I don’t see how labels work here. Labels are not Auditable and if a dispute was raised by the customer you can produce a verifiable version of the source code for an independent party to check.
Branching is a tool; it is not a silver bullet. Don’t over use it, and avoid “Anti-Patterns” where possible. There is a happy between no-branching and too-much-branching.

Notes on Software Design and Coding