Don't deploy on Friday and 3 other unwritten rules of software engineering
clubhouse.io
clubhouse.io
How painful it can be when you realize that your backup process was wrong from the beginning and you're left with a useless gigabytes sized blob when in need to restore your DB...
I really hate the whole "let's plan for a midnight deploy" paradigm... and find it very unconstructive.
When working on a few microservices with several deploys per service per day per programmer-pair, not deploying on a Friday means a ~20% productivity reduction. We had one of thosr days as there was an important demo day and our work got blocked in staging. When it finally does deploy to prod, you're exposing your users to all the changes at once and if there's an issue it's much harder to isolate the cause.
Our basic rule is don't deploy and leave any day of the week. If something does happen on the weekend, we're unofficially on-call via slack. I can only remember this happening maybe twice in two years.
And what's bikeshedding?
Unless you really want to work over the weekend.
If all you're doing is rolling out a new version of Postgres and it's supposed to just work, then a Monday deploy makes perfect sense. However, as a software engineer, the primary reason I've been involved in deployments is because we've written new code and we need to release it. In an ideal world, the code would be completed and rigorously tested by no later than Friday at 5pm. In the not-so-ideal world we actually live in, this isn't always true, which is why I prefer to target deploys for Wednesdays.
I feel like you're conflating deadlines with deploys. If its ready to go on a Monday then I see no reason why you should hold off doing the deploy. If you have to work all weekend to get it ready to go by Monday then its probably because there's a deadline.
First, why not demo partially complete and/or staged but not deployed work? Tangentially, doing things to appease sales is a quick way to reach local optima and build a directionless product (same thing for customers). A good product person will take their requests, identify the problems, throw out things that don't fit the vision, and incorporate the important parts. Sales shouldn't be your drivers, they should be your eyes and ears.
"ASAP" isn't a deadline. It helps you understand urgency, but not importance. Don't waste your time with urgent unimportant things.
> Management generally doesn't care when code is done, they care when it's done and deployed.
I'd argue that these two are the same thing. I'd even take it one step further and say you shouldn't consider your work done until it is deployed and verified working. Thats why you don't deploy on Fridays.
> Fair enough, but I'll observe that in my experience deadlines and deploys are often strongly correlated.
For some code this is true, but not all of it. I'm sure every team is different, but most code I deploy either has no deadline or has a deadline more than a few days out. Of the remaining stuff, deadlines can almost always be pushed back if the work isn't done. Not ideal, but usually a possibility. No need to work over the weekend unless there's a hard deadline which can't be pushed back, which is (or should be) exceedingly rare.