Never Ship on Fridays
octomind.dev
Never Ship on Fridays
1–10 of 55 posts
Re: Never Ship on Fridays
#2Probably someone who never had to fix a critical bug on a friday.
I mean it's like wearing a helmet on your motorbike, 99% of the time it is useless, but the day you crash, you better have it and not need it than the opposite.
Re: Never Ship on Fridays
#3There are three maturity levels, do not confuse them:
0: We ship to production whenever, why not? If stuff breaks, oops. People make mistakes.
1: We have processes in place to avoid bad releases. These include such measures as people agreeing to avoid Friday releases, and requiring manager approval of releases.
2: The processes are automated, and high enough quality that we can be confident that clicking the "go" button" will either result in the build/test/deploy pipeline halting due to a problem, or a good release going to production. We have no issue with Friday releases, or releases whenever.
Allen Holub is broadly correct. And if that author's "bigger release" happens a lot, then release size is more the issue.
Re: Never Ship on Fridays
#4There are three maturity levels, do not confuse them: 0: We ship to production whenever, why not? If stuff breaks, oops. People make mistakes. 1: We have processes in place to avoid bad releases. These include such measures as people agreeing to avoid Friday releases, and requiring manager approval of releases. 2: The processes are automated, and high enough quality that we can be confident that clicking the "go" but…
There’s actually another maturity level:
3. The processes are automated, and high enough quality that we can be confident that clicking the "go" button" will either result in the build/test/deploy pipeline halting due to a problem, or a good release going to production. But we still prefer not to release on Friday, because no CICD methodology is perfect.
Re: Never Ship on Fridays
#5There are three maturity levels, do not confuse them: 0: We ship to production whenever, why not? If stuff breaks, oops. People make mistakes. 1: We have processes in place to avoid bad releases. These include such measures as people agreeing to avoid Friday releases, and requiring manager approval of releases. 2: The processes are automated, and high enough quality that we can be confident that clicking the "go" but…
There’s actually another maturity level: 3. The processes are automated, and high enough quality that we can be confident that clicking the "go" button" will either result in the build/test/deploy pipeline halting due to a problem, or a good release going to production. But we still prefer not to release on Friday, because no CICD methodology is perfect.
There’s another maturity level: blah blah blah, but our CICD setup and overall code quality has long proven itself to be of such quality that we as a team / organisation have opted to assume this risk.
My real point is that, at a point, reasonable people can disagree about this, and calling these “maturity levels” strays further from reality and closer to the usual pass-ag nerd habit of mistaking personal preference for absolute objective truth.
Re: Never Ship on Fridays
#6There are three maturity levels, do not confuse them: 0: We ship to production whenever, why not? If stuff breaks, oops. People make mistakes. 1: We have processes in place to avoid bad releases. These include such measures as people agreeing to avoid Friday releases, and requiring manager approval of releases. 2: The processes are automated, and high enough quality that we can be confident that clicking the "go" but…
There’s actually another maturity level: 3. The processes are automated, and high enough quality that we can be confident that clicking the "go" button" will either result in the build/test/deploy pipeline halting due to a problem, or a good release going to production. But we still prefer not to release on Friday, because no CICD methodology is perfect.
This. Also, you rarely have a full idea how your downstream clients interact with the system that was changed.
Re: Never Ship on Fridays
#7"Never ship on Fridays" is pretty high up on my antipattern lust. It's a nice way to phrase "how about we work 20% less at the same pay? It will help reduce the number of bugs / incidents we ship each year!". And it will help with that.
But why do I say 20% reduction in work?
Bugfixes and features that get fixed/finished on Fridays will ship 3 days later. Do your average lead time increases by >0.5 days. This impacts anyone relying on you, too. So if this happens org wide then features and projects may ship days to weeks later.
Oh and what are you doing on Fridays then? Less relevant work? If you stick with priorities then you are just queuing up more changes for Mondays, leading to nice higher risk deploy Monday. You simply can't gain stability with skipped Friday deploys without changing / ignoring work priorities for Fridays.
So yes, this should be comparable to such a reduction.
Oh, and Friday deploys ruin your weekend? That means you have really high detection and mitigation time. With 1h detection time and 2h recovery I could still with low risk deploy Fridays, 5PM, wait 1h and enjoy a weekend after wrapping up my work.
I have always shipped on Fridays. It never ruined my weekend. Even though I did have a few fun screwups (which sometimes required help from my coworkers).
Re: Never Ship on Fridays
#8100% agree with Allen Holub. If your policy is no-ship-fridays because you're worried about things breaking and having to work the wkd, then your code quality is shit and you need to get better at being a software engineer.
Re: Never Ship on Fridays
#9Oh, they mean to never release on Fridays. I first thought that it is about shipping. I once bought something a little temperature sensitive and asked the seller to not ship on Friday so that the parcel has less time to be exposed to the temperature.
Re: Never Ship on Fridays
#10There's tech perspective tunnel vision here. There can also be an issue with the requirements the perfect code was written for, or some other non-tech downstream process.
A risk calculation exists here and included in mine is our on-call support team. I prefer no Friday releases.