Profile    Mohammed Shiroz Status   Loading  
Logo
Share This
Back to blog
Filter by:
Tags
//Article title

Me vs Production: The Friday Deploy

About Post

Every developer knows the rule: don't deploy on Friday. Every developer has also, at least once, looked at the clock, looked at a tiny change, and thought: "It's literally one line."

This is that story. You've probably lived it. If you haven't, a colleague has, and they still flinch when someone says "quick deploy".

Friday, 4:45 pm

The ticket is small. Change the wording on the payment confirmation screen and, while you're there, rename a column that's been bugging everyone for months. Tests pass locally. The pull request has one approval, given by someone who was also trying to leave.

✅ "Ship it. It's nothing."

Friday, 4:52 pm

The pipeline is green. The deploy runs. You refresh the page and see your new wording. Beautiful. You close the laptop with the smug calm of a person who has defeated superstition.

Friday, 5:03 pm

You're in the car park when your phone buzzes. Then buzzes again.

❌ The mobile app, the one still installed on most phones, is calling the API with the old column name. Nobody remembered the app ships separately.

❌ The queue workers are still running yesterday's code, because nobody restarted them. They're very confused about where the column went.

❌ A scheduled report runs at 5:00 every Friday. Today it sent an email full of errors to people who are definitely not developers.

Friday, 5:20 pm

Back at the laptop. "Just roll back."

❌ The migration renamed the column. Rolling back the code means old code expecting the old name, but the database now has the new one. The down() method exists, technically. Nobody has ever run it.

❌ Half the team is offline. The one person who knows how the report works is at a family dinner, typing replies under the table.

Friday, 7:40 pm

It's fixed. Sort of. The column has a new name in the database and a compatibility shim in the API, the workers have been restarted, and there's a hotfix in main that nobody has reviewed. You promise yourself you'll clean it up on Monday.

The new wording on the confirmation screen looks great, by the way.

Monday, 9:00 am

"So, how was everyone's weekend?"

The real lesson: it isn't about Friday

Here's the slightly uncomfortable truth. Friday didn't cause any of those problems. The deploy would have broken on a Tuesday too. Friday just guaranteed that the breakage met the fewest people, the most tired brains, and the longest time until anyone noticed.

The goal isn't superstition. It's making deploys so boring that the day of the week doesn't matter. These are the habits that get you there:

  • ✅ Deploy early in the week, early in the day. Ship when the whole team is around and fresh, and there's a full working day to watch it. Save Friday for small, low-risk changes, or for writing the tests you skipped.
  • ✅ Separate deploying from releasing. Put risky features behind a feature flag. The code goes out quietly; you switch it on when you're ready, and switch it off in seconds if something's wrong. No redeploy needed.
  • ✅ Have a rollback plan before you deploy. Not "we'll figure it out". Know the exact command or button, and know whether the database changes can survive it.
  • ✅ Make migrations backwards compatible. Never rename a column in one step. Add the new column, write to both, move readers over, and drop the old one in a later release. Old code and new code should both work at every step, especially when a mobile app version you can't update instantly is still out there.
  • ✅ Script the boring parts. Restarting queue workers, clearing caches and running migrations belong in the deploy script, not in someone's memory.
  • ✅ Watch it after it ships. Have error tracking and logs open for the first half hour. If you can't watch it, it's not the right time to ship it.
  • ✅ Small pull requests, real reviews. "Change wording" and "rename a column" should never have been the same PR. The second one deserved its own review and its own deploy.

The test for any deploy: if this goes wrong in five minutes, do I know exactly how to undo it, and will the right people be around to help? If either answer is no, it's not a Friday problem. It's a not-yet problem.

So, should you deploy on Friday?

If your pipeline is automated, your migrations are safe, your risky features are behind flags and rollback is one button: honestly, Friday is fine. Teams with good habits ship any day.

If any of those are missing, the rule exists for a reason. It's not about fear. It's about respecting your own weekend, and everyone else's.

What's the "tiny change" that ruined your Friday? I promise this is a judgement-free comment section.

Comments (0)
Leave your review

Thanks for your valuable comments. Your comments has been updated and appreciate your getting in touch...

01. About Shiroz

Mohammed Shiroz

Hi, I'm Mohammed Shiroz, a software engineer and AI enthusiast from Sri Lanka who turns ideas into intelligent, real-world solutions. With over 9 years of hands-on experience, I currently lead real estate ERP development at Kate Group, a...

03.My Projects

04. Categories

Ready To order Your Project ?

Get in Touch
Close