Photo credit: https://www.flickr.com/photos/spacex/44451125454/
A project manager recently told me that he wanted to implement a code freeze prior to user acceptance testing. This request struck me as odd since I don’t recall having implemented a code freeze on a project in years. My immediate response was that we do not need a code freeze. All checked in code is tested for its production readiness via a deployment pipeline.
The intent of a code freeze is to identify and lock down a known "good" state of the source code. The code can then be built, and then deployed from this known "good" state. If a developer checks in a change after a code freeze, then this known "good" state can be considered tainted. The intent behind implementing a code freeze is well placed, but the execution slows down a team’s progress.
The need to implement a code freeze demonstrates a lack of understanding of version control systems (VCS). Most VCS allow you to tag a particular known state of source code. By tagging a known “good” state of the source code, developers can continue checking in changes. The tagged known “good” state can now be built and deployed, without slowing down developers.
Deployment pipelines make this process much simpler to administer. As changes are checked into version control, the continuous integration server checks out the new revision and executes a build. If the change passes all tests in the pipeline, then the revision is tagged. Ideally, this tag maps back to the build number using a naming convention. This provides traceability.
So if you find yourself in a situation where you want to implement a code freeze, think twice before you do. It is likely that you can get around this by better utilizing your VCS.
Share this: