concept code freeze in category software development
This is an excerpt from Manning's book Agile ALM: Lightweight tools and Agile strategies.
The frozen zone isn’t the same as a code freeze (see figure 3.5). The code freeze is a short interval at the end of the frozen zone that spans a few hours, such as the last hours of the release or the last afternoon of the release. The code freeze is the slot where no one can commit anything, not even new features or bug fixes. It’s the time where the releasing team creates the final release. But the procedure of creating the release should be the same as creating the continuous versions. The purpose of the code freeze is obvious: to eliminate any changes to the artifacts. Changes made during the last moments of the release dramatically increase the probability that the next (and final) build will be broken. Although you did build the software continuously, no former build took the last (changed) sources, so the last build can fail. Because the release is strictly timeboxed, it’s important not to have any surprises on the last day or get any new bugs later.
Figure 3.5. The frozen zone and the code freeze for stabilizing and finally releasing the software before the next release is developed (F = feature; B = bug). The way testing is done in an Agile environment often eliminates the need to have a project phase dedicated to detecting and fixing last-minute bugs. There may be a few last-minute bugs, but the dedicated phase should be as short as possible. In the best case, the number of last-minute bugs doesn’t justify a scheduled phase in the lifecycle.
If you detect some final showstopper bugs, they should be fixed. But only one person or a special group should work on those bugs, under the highest quality restrictions. Restricting access on the VCS can be done by conventions. You can email your team and tell them not to change anything in the VCS (they may continue work in their individual workspaces), and then send another email later, releasing the code freeze. In some environments, though, this lightweight approach doesn’t work. If you have a chaotic team, hypermotivated people, or too many team members to inform with emails, you may want to support the code freeze technically (see section 3.4). Code freezes are important for providing stability and the chance to complete a releasable unit of work. Success also depends on a good release plan.