Tech News
I’ve seen the advice of not deploying products on Fridays 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 your development processes and tools that you 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 might there be a catastrophic bug in your production? Well, 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, 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. You 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!
Published August 14, 2019 — 13: 32 UTC
Pablo Román
August 14, 2019 — 13: 32 UTC