So… your team is using a distributed version control system like mercurial or git for some time already. You feel more confident with the merging tools and processes, it seemed more complicated than your good ol’ subversion at first, but now you and your team understand that you can never go back. Now what?
Because you want to release often, it’s natural to tie your DVCS to your integration and deployment system and have all your tests run automatically every time you deploy. There are many ways to work with the DVCS in this scenario, we are not going to get into that, but we use the so-called feature branches because it better adjusts to our particular team and present situation. We keep the feature branches as small (short-lived) as possible, and follow a set of rules that helps us dealing with this combined processes. I wanted to share those rules with you:
#0 – default (or master, in git) must be deployable to the UAT environment at any time, this means all the unit and integration tests must be GREEN at all times in this branch.
#1 – Merge to default as soon as possible, but always obey #0.
#2 – Keep your feature branch updated, otherwise #1 will be painful afterwards.
#3 – If your branch lives longer than expected or involves big changes, take advantage of all the points along the way where it is safe to meet #1, including #0. Do it.
Some related things you want to read:
- FeatureBranch by Martin Fowler.
- FeatureToggle by the same guy.
Content under Attribution-Share Alike 3.0 Unported
I like this post, because I guess the way we use feature branches is not the way Martin Fowler describes it:
http://jamesmckay.net/2011/07/why-does-martin-fowler-not-understand-feature-branches/
I don’t like feature branches very much, but you are certainly right about one thing: You have to use whatever branching scheme that better adjusts to our particular team and present situation, that’s the key.