Table of Contents

There’s a popular saying in software circles: “never deploy on Friday.” It’s half serious and half humorous, but the logic behind the saying is simple. If you deploy new code and break something, you have ruined (and delayed) the start to your weekend. Instead of clocking out for the day, you’re suddenly fighting a fire until it’s fully extinguished.

However, with sound operational practices, you can confidently deploy any time you like. I have four simple rules for deploying any day of the week:

Rule #1: Deploy Frequently

First and foremost, you increase confidence in a task by doing it a lot. So, to increase confidence in your deployments, you should deploy frequently! At Twin Sun, we encourage our team to deploy every time they complete a new feature. This means that any product may have several deploys every day.

Routine deployments have a couple of advantages. First, you quickly work out any kinks with your deployment process. Ideally, deployment is an automated process so any enhancements you make to it will benefit all future deployments.

Second, deploying frequently means deploying less stuff. A small code change presents a much smaller problem space than a week’s worth of code changes. Deploying a single change at a time reduces the time required to identify and fix production problems, should any arise.

Rule #2: Deploy Your Own Stuff

I’ve been caught holding the bag before on a botched deployment, and it’s awful. A coworker completes a code change but is leaving for the day. They ask me to push their changes to the production environment, and I oblige. Unfortunately, things go wrong and I have no context for what changed or why it caused a problem!

A handful of those experiences led to my creation of this rule. I flatly refuse to deploy changes for other people now. Deploying code you don’t fully understand makes diagnosing code problems very difficult. So it’s best to deploy your own code, soon after you have written it. You’ll still have the mental context for what you did and, should a problem occur, you’ll likely know what went wrong and why.

Rule #3: Pay Attention

This rule is a corollary to deploying your own stuff: pay attention when you deploy! It’s easy to start an automated deployment and move on to something else, but that doesn’t mean you should move on. Your changes are not fully deployed until they are verified to be working in the production environment. If you press the “deploy” button and turn your attention elsewhere, you won’t recognize if a problem occurs until it’s impacting a good portion of your end users.

Paying attention means watching your metrics, too. Your production environment should have good logging, analytics, performance metrics, and alarms to notify you if anything goes wrong. You should be watching your tools to ensure that the deployment introduces no surprises. For example, your error rate shouldn’t spike after a deploy, new errors should not occur, your CPU utilization on your web server should remain constant, and so on.

Rule #4: Build Good Guardrails

In addition to good monitoring that detects problems, set up good guardrails that prevent problems.

We introduce an automated test suite to every application we work on. Tests are a safety net: they prevent feature regressions and flag the introduction of unintended side effects in new code. Tests run before every deployment in our automated CI/CD pipelines, ensuring only code that passes all tests can make it to the production environment.

We also set up staging environments, so we can verify our changes in a close-to-production environment prior to rolling out changes to our end users.

Our web applications also use a rolling deployment strategy, so we can expose newly deployed code to a subset of users before broadly rolling out changes to everyone. This helps us identify problems in higher-risk code changes while minimizing the impact to end users.

Additionally, we have methods to roll back code changes or turn off problematic features. We have daily and incremental database backups so we can restore corrupted databases.

In other words: we make it difficult to make serious mistakes and easy to recover from them.

Go Forth and Deploy On Fridays

If you follow the above rules, you can deploy any time you like. Now, would I deploy at 5:00pm on a Friday? Not if I had plans at 6:00pm. The same is true for Monday at 11:00am: I might wait until after lunch before changing something important.

Here is the underlying theme with my four deployment rules: give yourself space to deploy well. You can then deploy whenever you like. When your changes are small, comprehensible, measurable, and revertible, there is little to worry about.