There are plenty of memes regarding deploying on Fridays and most of them seem to be about how you should never do it. I find that strange. In fact I think that every team developing a software product which ends up deployed on a production server (trying to exclude on-premise software releases, work with me here) should have a rule stating that there shall be no less than two Friday deploys per month.
It sounds strange, right? Why two? Well, I’ve started with a mandatory Friday deploy each week. That turned out to be unpractical, though. You can’t always plan for changes to be ready for merging precisely on Fridays.
On a more serious note. Let’s go through what issues people tend to have with deploying on Friday:
Most developers are already in weekend mood, they’re not that focused thus it’s
more likely to make a mistake while deploying. If developers are manually
deploying instead of a CI/CD, you have a problem to fix. Developers shouldn’t
have to do anything more than pushing a button to initiate a deploy (preferably
the Enter button on a
git push command).
There might be an ugly bug. Do you have tests, do you do code reviews or probably have a QA team? If not, think about it. If yes, then you know that there are still bugs that slip through. Just rollback.
But rolling back is hard, it takes time and people are already in that weekend mood, remember? That means your rollback process is more than a push of a button away. Go fix that.
Spotting bugs is harder on weekends. Why? Do you have people manually staring at logs and graphs? Setup a proper monitoring system. I guess your product doesn’t close doors on weekends, so you need it anyways. If it does, though… well… you got me.
But, but… many thing could go wrong you can’t even imagine! Yes, that’s most probably right. What difference does it make if you deploy it on Wednesday? It’s still good to be reachable a few hours after deploy especially if there are no people on-call 24/7, anyways.
Aim to deploy on Friday (preferably in the afternoon) every once in a while. That will force you to set up solid deployment and monitoring procedures (and habits in that matter) you really trust in.