Don’t Fucking Deploy on Friday

If a change isn’t safe to deploy to production, don’t do it on Friday. Don’t be a jerk and spoil the team’s weekend. But it points to a symptom of a greater problem — exactly why is it not safe to deploy that change on Friday?

This lack of safety can be for a number of reasons, but it’s very valuable for a team to be able to ship the vast majority of changes to production at any point in time. The pursuit of bulletproof deployments remains undefeated in it’s ability to yield incredible across-the-board improvements in reliability and velocity.

It takes investment, however. Serious investment. Extensive automated testing is table stakes. The code can’t be a technical debt freak show full of landmines. Builds and production deploys must be automated and very reliable. In the event that a bug sneaks past the automated tests, the deploy system should be able to detect most of these cases and roll back, while minimizing user impact. Release and deploy must be decoupled. The list is long. If you don’t have nice things, then Don’t Fucking Deploy on Friday.

It’s a simple goal, but all of the things you’ll do will force everything to become substantially better. Friday deploys ain’t easy. But they’re worth it.

All that said, personally, I still don’t merge discretionary changes after noon on Friday. Or if I’m about to go on vacation, or if there’s an open incident, or if the rest of the team is likely to be distracted. It can wait.

You can be kind to yourself and kind to your team, and also deploy on Friday. Put in the work, and you won’t regret it. ✌️