You're finishing up a release and also need to start continue development on the next release. You want to maintain an ACTIVE DEVELOPMENT LINE (5).
How do you stabilize a codeline for an impending release while also allowing new work to continue on an active codeline?
Before a release is ready to ship, there is often much work to do to get the active development line shippable. There are last minute bugs to fix, details related to installation and packaging and other last minute details to tend to. It is best to not do any major new work on the active development codeline while this clean up is going
on, since you don’t want to introduce any new problems. You will want to have very restrictive check in and QA policies during this “clean-up” period.
One solution is to freeze development on the active development line until the release stabilizes. You can institute a strict policy that only essential changes are made to the codeline. If things go well, this may only take a day or so. But the stabilization work may involve part of the team however, and there is new work to do for the next release, so you really do not want to stop work at all. And if the code freeze lasts longer than this is very wasteful of resources, and frustrating to developers who are doing new work, since they will have to work without the version control system. If people work on the changes without checking them in to the version control stream, you lose all of the benefits of having a version control system, and out yourself at risk of having chaos when the freeze is lifted.
Another possible solution is to branch the codeline into a release codeline, and do all of your work on the branch. If you branch too early, you will have to do a lot of merg-ing between the release line and the mainline. Branchmerg-ing gives you isolation, but at the expense of added work in doing merges.
Developers want to get work done, and avoid merges. Management wants the cur-rent code to be stable.
Idle Hands
Lots of places I’ve worked have instituted code freezes before releases. This is a good idea in principle, but when the code freeze lasts days or weeks, it seems like less of a good idea. The stated reason for freezing instead of doing something that allows parallel work is that it is less work. Of course, it adds frustration, and delays the release.
I’ve seen this so many times, often at the same time when there is lots of pres-sure to deliver code. Version control tools offer the ability to allow concurrent work, but they aren’t used often, or well.
Branch instead of Freeze
Create a release-engineering branch when code is approaching release quality. Fin-ish up the release on this branch, and leave the mainline for active development.
The branch becomes the release branch.
You mark the release of a product with a branch. Instead of branching off immedi-ately after release, branch before the release. This allows you to branch instead of freeze. Instead of freezing the maine codeline during release engineering activities, create a separate line for release integration and engineering and allow other devel-opment to continue taking place on the develdevel-opment line.
Create the release engineering line when the code is approaching stability. The closer to “done” code you create the branch, the less merging you will have to do between this line and the mainline. The trade-off is that you wait longer, you may find your-self in a code-freeze situation.
This anti-freeze (release-engineering) line becomes the release-maintenance after a successful release. It still serves the same purpose of “sync and stabilize” but now it is an ongoing effort that continues even after the release.
In reality, there may be a small “freeze” window -- as long as it takes to create a con-sistent branch. If you can avoid this, all the better, but even if your “freeze” is short, you are still ahead of where you were when you had to freeze until you ship and release. Figure 18-1 illustrates this structure.
Changes can take place in each of the two codelines at the appropriate pace. Critical fixes and enhancements can be implemented and delivered without immediately Figure 18-1 .Release-Prep Code Line
impeding future development. Maintenance releases or “patches” can be periodically released without severely impacting development on the next release. The Code Line Owner of the development line can set a policy for how and when changes are prop-agated from the maintenance line to the development.
Unresolved Issues
If only a few people are working on the next release, instead of starting a release prep branch, start a Task Branch for the new work.
To keep the codeline in good shape while you are doing a potentially disruptive task, consider using a TASK BRANCH (19). This pattern forms the basis for a RELEASE LINE (17).
Software Configuration Management Patterns: Effective Teamwork, Practical Integration by Steve Berczuk with Brad Appleton. Copyright 2002 Addison-Wesley, Boston, MA. All rights reserved