What guidelines should be followed when using an unstable/testing/stable branching scheme?

My team is currently using feature branches while doing development. For each user story in our sprint, we create a branch and work it in isolation. Hence, according to Martin Fowler, we practice Continuous Building, not Continuous Integration.

I am interested in promoting an unstable/testing/stable scheme, similar to that of Debian, so that code is promoted from un开发者_高级运维stable => testing => stable.

Our definition of done, I'd recommend, is when

• unit tests pass (TDD always),
• minimal documentation is complete,
• automated functional tests pass, and
• feature has been demo'd and accepted by PO.

Once accepted by the PO, the story will be merged into the testing branch. Our test developers spend most of their time in this branch banging on the software and continuously running our automated tests.

This scares me, however, because commits from another incomplete story may now make it into the testing branch. Perhaps I'm missing something because this seems like an undesired consequence.

So, if moving to a code promotion strategy to solve our problems with feature branches, what strategy/guidelines do you recommend? Thanks.

Update: Fowler discusses Feature Toggle (http://martinfowler.com/bliki/FeatureToggle.html)

I think you may be missing something, or asking for a logical impossiblity. Functionally, there are two ways of doing the merges from "unstable" to "testing". Either you can merge in only the code associated with a given "done" story, or you can merge everything from unstable to testing when a story is finished.

These have advantages and disadvantages. The advantage of the first is that things only end up on the testing branch when they're complete, so you don't have parts of incomplete stories outside of unstable. The disadvantage is that the parts that you merge may depend on parts that you didn't merge, so the merge isn't just a simple copy. Alternately, the advantage of the second is that merging is trivial (just a copy, no thought required), but you end up with incomplete things in testing.

Functionally, in some ways the first option is like having different feature branches except they're all in the same tree. You still have to have some way of tracking what code is part of what "story", and you have to disentangle the various pieces in order to merge some particular bits of it into testing, and you have the problems of interdependencies and so forth as a result of that disentangling. As a result, this merging policy may not actually get you very many of the benefits of Continuous Integration -- but, in some situations, it may be a good tradeoff, and preserve some benefits of Continuous Building that are more valuable to your project.

On the other hand, it sounds like a fair part of the point of Continuous Integration is that things are continuously being integrated into the main trunk, rather than only being integrated when they're "complete". Thus, if you're thoroughly buying into that philosophy, it seems to me that having incomplete things in your testing branch is the expected situation -- it's inherent in the philosophy of the system.

It's worth noting, though, that Debian et al are functionally following the first approach; things are only merged from one stage to the other in a piecemeal fashion when they're complete at some level. To some extent, things can be simplified by only merging code-entangled "stories" together when all of them are complete, but there is a lot of work in "backporting" patches in order to merge things from one level to the other. Although the idea of having a three-level unstable/testing/stable structure seems useful for Continuous Integration, I don't think much of Debian's policies beyond that will carry over if you're using the merge-everything philosophy.

You don't have to take Martin's words too literately. Different approachs may apply to different situations

• If each feature's code base is isolated, you probably don't need to worry too much about the merging problem Martin mentioned.
• If it's the refactoring problem that worries you, you may try first to refactor and then plan the next feature. Make sure that each refactoring should be relatively small. So your workflow would be: small R...feature..merge..small R...
• If it's the code-quality of a feature branch that worries you, and you don't auto-build each feature branch, maybe you should start trying auto build and auto test each branch.
• If you worry that a PO makes a wrong decision to move a unstable branch to test branch, that's probably a human problem. Anyway, auto-build-and-test may help him/her make the right decision.
• No matter how much you have done, mering problems happen. That's why you need testers and test branch and CI etc. Do your best to weight the cons and pros, then live happily ever after. :)

There's a very, very strong explanation in the following two links:

1. http://nvie.com/git-model
2. http://codicesoftware.blogspot.com/2010/03/branching-strategies.html