If you're afraid of deploying on Friday you should be scared of deploying on weekdays as well
If you're in a software or product company I'm sure you have heard the advice of "don't deploy on Friday." This is both reasonable and has merit. However, this isn't great advice in 2023.
By now you've had plenty of time to invest in tooling around your deployment pipeline. I can hear you now, "But Friday is a good day to deploy because everyone is off and I don't have to worry about users seeing my mistakes.", in that case I don't know what to say.
The phrase "Don't deploy on Friday" is shorthand for some sort of a Fridayphobia mantra that has no place in modern product companies. It's an old belief that persists among many developers: deploying on a Friday would bring bad things...
I am going to talk about why this advice came about in the first place, why it's not relevant anymore (there are exceptions), and what can be done instead.
Bugs will be in production longer
The rule came about from a time when deployment was much harder and a big deal. Software teams would plan releases weeks in advance where often big pieces of code were deployed all in one go. Chances to break stuff were significant.
And obviously, we want to make sure that your team can enjoy their deserved weekend and not have to spend their Friday evening debugging just because someone decided to deploy a big change right about when you were packing your bag for a camping trip.
Or maybe the whole process of deploying code is cumbersome and error prone and you don't want to risk having to stay around later and figure stuff out.
Why is this a problem?
One primary drawback of avoiding deployments on Friday is the slowdown in the shipping capabilities. By following a stupid "no-Friday deploy" policy, valuable time on the calendar is lost each week. With each passing Friday, you miss out on the opportunity to deliver value and stay ahead.
Furthermore, avoiding deployments on Friday can contribute to a decrease in team trust. Modern development practices have solved this problem. When a team consistently refrains from Friday deployments, it sends a message that there is a lack of confidence in the overall system.
And although an important component of efficient companies is to be risk-averse that does not apply here. The risk management should be done by breaking up features in workable, deployable chunks that can be deployed and provide learning oppertunities.
In summary, refraining from deploying on Friday will slow the company down and undermine team trust.
The obvious solution - make deployments boring.
The obvious solution, then, is to make deployments constant and robust. You want to make deployment as boring as possible. That way it's a low-barrier activity and a boring process of pushing code to a server and having it run in exactly the same way whether you're deploying on Friday afternoon or at 3 on Monday morning (or any other time).
That means automating every aspect of deployment from start to finish - from triggering the deployment, building the new version of your app in CI/CD, provisioning servers, etc., all the way until making sure everything still works correctly when deployed.
This is the approach we're taking at Prezly which is working pretty well. In addition to a PR review (by another human) we have a set of tests and automation that makes sure everything is working as expected. Additionally, we have a lot of alerts in place that are triggered automatically based on application logs, error codes and speed reports we all capture in our logging datastore. We are able to deploy code dozens of times a day without disrupting users or causing problems.
The advantage of making deployment boring is that product teams start to use that to their benefit where they constantly ship small iterations and improvements instead of large chunks of code.
And although this gets you a long way, it's not a silver bullet. You should never be 100% confident in your deployments just because you have tests.
Easy rollback
Mistakes will happen. The question isn't how often mistakes are made but rather how well they are being handled.
A great CI pipeline should have a 'rollback' button somewhere that switches the application to a previous/working version of the app. This should keep in account any database/schema migrations and have a good mechanism (database migrations) to rollback any changes you made to the database.
Apply the 'no Friday' rule when it makes sense
For the reasons laid out in this post I think the no-shipping-on-friday rule is generally bad, it is important to ackowledge that there can be legitimate exceptions to this rule.
Sometimes there will be changes/improvements/upgrades where there is more uncertainty. Although I'd still argument to try and find a way to decrease that uncertainty there might be a good case to wait for Monday.
Some examples:
- Upgrading the database version. This might introduce unexpected effects that are hard to estimate only by having a good testing suite
- Decommissioning a feature. Lets say you've been testing a whole new layout for the app and are happy with the feedback/experiment by a % of your users. Setting this as a new default and enabling it for all customers might be better on Monday as you can expect an increase in feedback/conversations
- Huge feature releases. Although we try to avoid this there are cases where an event or build-up of a new feature (please don't say AI) will result in an one-off hocus pocus ta-da moment. For any case where you're pushing a large PR/changeset to your production database i think if you have the choice it's better not to do it on Monday.
Conclusion
Now that you know this rule isn't just outdated, it's also counterproductive.
You can take the same approach to deployments that you do with everything else: make them routine, plan for them in advance, and prepare your team for success by eliminating siloed environments and automating as much as possible.
Good reads:
