Only deploy on Fridays

There’s a poster next to my desk with “Only deploy on Fridays” written on it. The poster is visible on Gigs’ Careers page, and from time to time, colleagues and applicants mention it or ask me about it.

Last year, Daniel sent me a photo of some scribbles he made with funny work-related sentences in a very artsy and typographical style. One thing led to another, and sometime later, I received this poster in the mail. It’s a phrase he picked, based on topics that we often discussed.

Of course, the statement to only deploy on Fridays is exaggerated and satirical. It’s an obvious nod to the “Don’t deploy on Fridays” rule—something I encountered a few times in different jobs and projects, but I can’t identify with.

Restricting deployments to certain days or times is a bit of a short-sighted mentality. Some people are very afraid of deploying to production, but that’s not how it should be. If you’re afraid of it, instead of doing it less often and continuing to be afraid of it, do it more often and take the fear out of it until it becomes second nature.

You should always deploy. Do it on weekdays, evenings, Fridays, weekends—whenever you finish an increment of work. But do it with common sense and responsibility. If you’re deploying something that could have an unintended impact and you need to monitor its rollout, it doesn’t make sense to trigger a deployment and immediately close your laptop. It’s not a very responsible thing to do.

Just because you’re deploying on a Thursday instead of a Friday doesn’t give you proper confidence that it will continue to work over the weekend. You still have to be confident in your changes regardless of the day or time. You can’t skimp on writing tests just because it worked on production for a few days. Conversely, when you’re confident in your work, the day or time of deployment doesn’t matter.

Better yet, decouple the act of deploying with the act of releasing. Put your work behind a feature flag, continuously work on your feature behind this flag, and ship multiple smaller increments to production. Users won’t be impacted by your work in progress because it’s not yet released to them. When the time is right, enable the flag and start rolling it out to users. If you notice unintended side effects, like a spike in errors or something that doesn’t work as expected, you can just disable the feature flag again with a simple click, and the crisis is averted.

I believe that working with Continuous Deployment is an important tool to improve your skills as a software engineer. And Continuous Deployment can’t stop on a Friday: it’s continuous. Some people will be skeptical at first: when I first introduced Continuous Deployment at Gigs, some colleagues were skeptical, some new joiners had doubts about it, and some candidates I’m interviewing sometimes question how this should work. These doubts will always fade away, and everyone will see the benefits. I think they are skeptical at first because it requires you to approach your work from a different angle. It’s different from making larger releases with breaking changes, and not everyone is used to working like this. You have to work in backwards-compatible increments, and you have to increase your confidence in your changes. But all of these are good things. Having the confidence to deploy on a Friday, just like any other day, is a freeing experience.