End-of-release Branching Strategies

of a single integration point, agile teams use a variation of the main line pattern called an active development line, which is structurally like the main line-a single code line-but with policies that help to ensure that the code line is always at a certain level of quality. Some of these policies include writing and running automated tests before committing changes and setting up a continuous integration process that validates the code compiles and runs all tests successfully.

Figure 2: Common code line structures

There are alternatives to the agile, active development line approach, but in the end they defer problems. Your team can make more progress by helping to keep the development stream working both by exercising a reasonable amount of care before commits and also working together to immediately fix problems that might have slipped by.

Release Branches
Regardless of your development approach, it is often necessary to provide an urgent fix to code that is being used by customers without introducing additional features or functionality.

In spite of your desire to maintain shipping code, it will take time to get your team and your process to a point where you can reliably ship from the main line, so branching at or near the end of a release may be useful. This requires a parallel development stream. This development stream can evolve into a release branch that will allow you to easily fix critical issues that can't wait until the next release, so teams have processes in place to integrate these changes back into the main line by merging.

In part two of this article, I'll discuss some approaches to using your branching as a way to help you to deliver a solidly-tested product, while at the same time allowing you to begin new work while the release is being finalized.