I’ve seen this advice over and over in my Twitter feed and internet memes. I even stumbled upon a job offer that mentions “no Friday deployments” policy as one of their perks. Most of the industry is now sold on the idea that pushing code to production on a Friday is a bad practice.

I understand the reasoning behind not doing a big product update on a Friday. The reasons may be technical but also tactical: All the teams involved in a big launch need to ensure there is a proper communication strategy, everyone is ready to answer questions from customers and the press, and the technical team is around to monitor and troubleshoot any issues.

‘No Friday deployments’ is an anti-pattern

However, the phrase “We don’t deploy on Fridays” sounds unprofessional to me. It reflects a lack of confidence in our development processes and tools that we should try to fix instead of assuming as a religious mantra that releasing code equals to chaos.

I do see the point of the argument though. Obviously no one wants to waste their weekend chasing a catastrophic bug in production. But why a catastrophic bug in production could possibly happen? Let’s name a few reasons:

  • Your testing or QA process failed to identify the issue.
  • The monitoring systems did not alert you before it was too late.
  • Rolling back or releasing a fix is a long and complicated process.
  • Too many things changed at once in your release, which made catching the bug very difficult.

Luckily all of these issues can be mitigated with the right planning and investment in modern software engineering techniques.

How to deploy safely on Fridays (or any other day of the week)

The most efficient and productive technology teams release multiple times a day (also on Fridays) by using these techniques. This is not a comprehensive list but just a few ideas -each one of them worth an article of its own, probably- that will reduce risk and uncertainty when taking code live:

  • Release often. The more often you do it, the less it’ll hurt.
  • Reduce scope. For both business goals and your own sanity, it’s better to plan a dozen of small releases than one big deployment at the end of the month.
  • Write tests. Seriously, write tests. Don’t need to go overboard but make sure all the critical parts of your systems are well covered by automated testing.
  • Implement a repeatable and reliable build and release process to reduce cognitive overhead and add some extra peace of mind.
  • In case everything else fails, make sure rollbacks are easy.

Does your team release code on Fridays? I’m interested in hearing your story. Let me know your thoughts on Twitter!