In which case, why wouldn't you deploy it during the weekend? That way, you're already prepared to be working several hours on a Saturday (presumably earning overtime rates) and so it's no major issue to rollback if it goes wrong.

Friday deployments make no sense if you have teams that work Monday-Friday.

▲

Geezus_42 7 hours ago | parent | next [-]

Friday afternoon is not unusual if you are facing a weekend deployment. Might as well try to get it done Friday afternoon an not have to worry about it the rest of the weekend.

▲

hinkley 12 hours ago | parent | prev [-]

Several hours. That number goes up quickly when the bus number for something that broke unexpectedly is unavailable. While your coworker who actually knows what that error means is at the zoo with his girlfriend or with his kids.

The whole point of WLB is that we don’t live like monks.

▲

Geezus_42 7 hours ago | parent [-]

Why do you only have a single co-worker that knows that error? Why hasn't anyone written shared documentation?

	▲	hinkley 6 hours ago \| parent [-]
		Outages are caused by change. Sometimes user traffic, but more often your coworkers. Do you know how every feature toggle in your system works? Do you know the potential blast radius of those toggles? Can you speculate on the surprise surface area that might be additionally exposed by impedance mismatches and side effects (ie, unanticipated shared state)? Hell does every engineer who wrote a feature toggle know this about their own code? You know who I’m talking about. If you’re having problems in production that can be anticipated, why are you still having those problems? How long should those be tolerated before someone gets fired?