Deployment Freeze in Harness
“In software, when something is painful, the way to reduce the pain is to do it more frequently, not less.”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
The software delivery world is leaning more towards continuous delivery these days where small changes are shipped to production very frequently. To achieve this, the delivery process must be very quick and automated. We can have triggers configured to start a new deployment whenever an artifact is pushed into a repository, new build is created or code is committed into the master branch of a repo. In Harness, these automatically triggered deployments can be made to complete with as less manual intervention as possible such as a few approvals from Jira/ServiceNow and notifications in slack/email after the deployment is over.
But with these automated deployment processes on regular schedule, sometimes we might not have enough resources and people to monitor the deployments if something goes wrong or perform regular sanity checks after deployment such as during holiday weeks. Sometimes a business critical company event might be going on where bugs and regressions which could be potentially introduced by a new deployment must be avoided at all costs. In these cases, it is useful to configure what we call a 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. Freezing all deployments doesn’t mean all production instances are brought down but rather new changes are not deployed to production. The services in production keep running with the latest build before freeze started and keep serving clients till the freeze window is over.
Now let’s take a look at such a freeze window we use in harness:
This freeze window is configured to stop deployments in Harness from 12 am, December 25th of 2021 to 11:59 pm, Jan 2nd of 2022. The deployment freeze can be also configured to be applied only for certain applications and environments. In this example, there are two applications used in production — Harness Sample App and Demo Deploy. Harness Sample App is configured to freeze deployments only for production environments whereas Demo deploy is configured to freeze deployments for prod and QA environments. This is particularly useful when we still want to deploy our app in staging environment for feature testing during holidays but don’t want the new builds to make it to production.
When a deployment freeze window is active in Harness,
- No pipeline/workflow executions are allowed to be started which make deployments in an application to a certain environment. The deployment buttons are disabled and APIs throw an error message.
- Ongoing deployments are stopped (‘Rejected’) when the pipeline hits a stage with frozen environment/application. These deployments can be continued from the frozen stage after the freeze is over.
- The automated deployment from triggers concerning the frozen application/environment are stopped before they start too.
We receive notifications for the rejected deployments or when a deployment freeze gets active/inactive in slack/email to the user groups configured in the same window. The details about the freeze window and the pipeline are provided in the same notification message so that we can easily access them from the hyperlinks provided.
With these deployment freeze windows setup and configured, we will get a notification once the deployment freeze starts. Then we can go enjoy our holidays in peace knowing that our production environment will be stable and won’t be affected due to any new changes. And once we return back from the holidays, we can see a list of all pipeline executions rejected in slack/email and we can pick the executions we want to continue, resume them from the frozen stage and get those builds deployed to production in no time!
