Is Code freeze still relevant?

When practicing CI/CD, does code freeze still matter?

Assuming you are familiar with the concept of code freeze, which is that dedicated time in a project when we (developers) are supposed to be more strict in making changes to the code or other resources for the good of moving the project towards a release or the end of an iteration.

I’ve recently wondered about that concept; I asked myself why do we need to stop everything when we have a full-scale CI\CD pipeline. Well, you can just pick one of the versions and set it as the release candidate.

I researched and asked around, below you can find my conclusions.

Code freeze? Aha?

First thing, first, defining what code freeze is. Wikipedia defines it as:

a freeze is a point in time in the development process after which the rules for making changes to the source code or related resources become more strict

The page underlines 3 common types of freezes:

A specification freeze is when all parties agree that no new requirements, specifications, or features will be added, as well as stop coding.

In a feature freeze , all development of new features is suspended so that all effort is focused on finding and fixing bugs and improving the user experience. A feature freeze helps improve the program’s stability by preventing the introduction of new, untested source code, resources, and their interactions.

Lastly, a code freeze , where no changes are allowed to the source code, ensures that the code areas known to work correctly will continue to do so. Code freezes are more common in the final stages of development when a specific release or iteration is being evaluated.

Do we need it at all?

Now that we all synced what it is, the question is whether it’s relevant nowadays, where most (I assume) organizations practice a sort of CI\CD pipeline? the answer is not so simple; it depends on the domain and the product’s needs.

Take for example what happens at Igentify (where I work), the product we develop is regulated as required in the health tech domain. We apply a feature freeze for that purpose, so all features will be stable, the code is shifted to a dedicated branch, and (manual and automated) tests are applied before release. If any bugs were found, we fix them ASAP. In the meantime, new features are being developed in the main (current) branch. So, newer development doesn’t stop; it gets lower priority, and the pace is slower.

Whereas this notion contradicts the concept of the CD (commit == new version) where you can just take whatever is ready (in terms of code, tests, etc.) from a specific branch and deliver it to production. For instance, if a bug was found, quickly fix it, push and deliver to that branch. In a way, It creates a buffer between developers and production. They can continue to do their work without knowing there is a freeze at all.

In some cases, it is worth “breaking” the CD concept to mitigate a release risk. For example, I’ve learned that Big Tech companies such as Google do code freeze on the holidays since most of the employees are with their families, which results in less workforce to overcome production issues.

A word of caution ⚠️

We should stay on guard about the frequency of using a freeze, it may point to unreliable tests , hence strengthening the testing chain will reduce the need for it. Moreover, some might argue that your processes have problems since you say certain contributions can’t integrate. There are many possible reasons, such as:

• No automated tests.
• Slow and\or flaky tests.
• Long feature branches.
• Unagreed design changes.
• Broken builds are not being immediately reverted.
• Developers don’t work on the latest main trunk.

Whatever it is, you’re not doing CI if you cannot integrate without stopping the whole team.

Final words

The truth is that there are no absolutes here.

The point of continuous integration and tests is to shorten the feedback loops and give programmers more visibility. As a result, there are fewer problems in testing and builds, but this doesn’t mean you don’t do the other parts of your development cycle — they’re just more efficient and effective, as development-related issues are more likely to be caught earlier in the process.

Nevertheless, a high degree of confidence does not mean something should go into the release without passing through the same final stages, and the code freeze is a critical element of this. To ensure the baseline for what you ship is as expected, you will still need it (or at least a branch).

Note that, simpler cases probably don’t require freezing. The CI process should ensure that a development branch's state can be released. Though, there can be MANY reasons why some specific code cannot yet be released into production. It is possible that other dependencies are required to be released at the same time or for any business reasons.

In any of the cases, IMHO, the release risk has to be managed, in some cases on the account of reducing the CD rate, though we shall strive not to harm it and find other ways.