Deployment freeze

A Deployment Freeze is a specific window of time during which no deployment is allowed to be made to a specific or all environments. Is…

A Deployment Freeze is a specific window of time during which no deployment is allowed to be made to a specific or all environments.
Is this solving something?

A lot of big companies implement any kind of deployment or code freeze during high traffic period. I’ve worked in companies that do deployment freezes, and just one which did once a code freeze because of an emergency.

Deployment freeze

In my experience, deployment freezes are counterproductive. Deployment freezes have only sense in companies that deploy different services with a good cadence. You don’t need a deployment freeze if you deploy to prod every six months. Also, if you are in a monolith deployment freezes are less risky, probably because your company is not designed to deploy multiple times per day or week.

Then if we push our company to multiply the number of deployments, and we designed it for doing it (for example using microservices and teams per domain), what’s the consequence of forcing the whole mechanics to stop?.

The consequence is increasing the risk of bugs in production when the deployment freeze disappears. Because we will deploy big bunches of changes, bigger than the ones we usually do. 
In order to avoid this risk, we typically add bureaucracy in the form of deployment windows per team, department or whatever, to coordinate deployments in the same way we did before when we were working with a monolith.

A simple case when this can be a disaster are two teams changing two services tightly coupled between them:

• Service A is changed by Team A because of a new feature introduced

• Service B is changed by Team B, new API added included

• Service A has been changed by Team B also to use the new API in service B

So team B knows that Service A and B needs to be deployed together, but this info is not know by Team A. So if team A deploys their services before team B there will be a bug in production and team A will not understand anything. This problem is always there, but with large periods without deploying changes to prod, the possibilities to happen are higher.

This specific issue is an architectural issue that is reflected in the teams' coordination. The usual response to this kind of incidents is to add more bureaucracy trying to solve the coordination issues, but the real issue is not that one, is the reason why two teams need to change those two services. 
In fact, when two services talk a lot between them, the people working in those codebases need also to talk between them, we need coordination.
When a company deploys with high frequency to production, this issue is less usual because production coordinates people. We can check which versions are deployed if they're compatible with our changes etc. We can test against production, for example, using the canary release technique.

But if we stop deploying, and we still develop new features, then the risk to fall down in this problem is higher for each day it passes.

Features freeze

In my opinion, Feature freeze is a consequence of bad technical decisions. At some point, you will need to stop and fix all the stuff you have created. This happened to me in the past when we were replacing an old monolithic architecture by a new fancy microservice system. 
I wrote about the consequences of trying to start from scratch in this blog, another consequence of this is feature freeze.
In fact, feature freeze is a very difficult decision to take because no one wants to admit they were wrong. 
Feature freezes are not adding deployment risks. Feature freezes try to improve quality of the product without adding new features. The issue feature freeze creates is a more psychological thing, it’s probing we failed. This is not a real bad thing, can be a starting point to learn and improve for the future. But not everyone can accept a big fail, so there are a lot of resistance to continue with the freeze (usually by managers in charge of the project).

Feature freezes are increasing another kind of risks, depending on how much time are we fixing things there are more options to be fired. Companies don’t have patience to wait for things because they lose money, in this kind of situations the cost is easier to measure and there is no benefit at all.

As a summary, any kind of freeze for me is an architectural smell. Architecture and culture of the company are very related so even if they exist because of fears, those fears were created in the past and not solved yet. 
These smells only guide us to identify the real problems we have at cultural or architectural level. 
It’s worth to fix them, don’t try to solve them through improving people coordination.