Not to jump on your comment (since there have been quite a few other replies already) but just to add another personal anecdote: having been on the more senior end of a junior merge/deploy gone wrong and losing a Friday night or a weekend ping, I'm okay with an additional empty day throughout the week.
I've found that little things like that breed a growing resentment and stress that compounds, until someone wants to leave the company. Thursday night outage that I have to hop on? Much smaller deal than a weekend where I have established plans.
One can argue "why was the PR approved in the first place", but sometimes people make mistakes. It especially sucks when there are limited people that know how to troubleshoot and resolve the production issues with a system, even more so when the on-call individual may have not even reviewed the code initially.
All that said - I'd love to deploy as normal on Fridays! I've just found that the type of businesses I've worked at can wait until Monday, and that makes our weekends less risky.
I understand the article's emphasis on exercising good judgment around release timing, but read-only Fridays are not there for the people who generally exercise good judgment. If you are the sort of person/team that is likely to deploy late on a Friday afternoon despite the inherent risk, you are likely the kind of person/team who underestimates or ignores risks in general. This includes the risk of a given deployment, thus exacerbating the impact of your late-Friday deployments. It is therefore sensible to simply take the decision out of your hands.
I hate how people hear "read only friday" and decide to turn it into a CI/CD dick measuring contest.
For "read only friday" to have been a novel idea in the first place, you needed a starting point where conventional practice already was making changes live without stopping to consider the time/day of week.
I really suspect the detractors represent a workflow that would break (or at least introduce pain) if unable to push to production for a few days. So they have to give the hard sell on the benefits of continuous deployment.
Perhaps. But what's the risk-reward? No matter how good your CI/CD is, the risk is nonzero. Do I really need to ship this today and potentially open a can of worms this afternoon?
To counter the counterpoint.
Even if you are better at pushing to production than 90% of the rest of your industry it is still elevated risk and stress so you should avoid it for the sake of your employees. Productivity vs life.
If your counterpoint is to claim that you are just as stable pushing to production as you are when you don't, then I would just suggest you're delusional or lying.
This post is weird to me, because it sorta feels like it's attacking a straw man.
The idea the author seems to be advocating for is is that, while maybe you sometimes/often shouldn't deploy on a Friday (or even not at the very end of any workday), there should never be a stated policy in place that freezes deployments.
And yeah, I've been at places where they have freezes on weekends, holidays, right around the company's conference, etc. But they're never 100% freezes: if something goes wrong or is necessary, you just get a manager to approve it, and off you go.
I think the author's exhortation that developers should all be able to exercise their judgment to make these calls is a nice idea in theory, but falls flat in practice. Every developer will not always have all the necessary context in order to exercise that judgment. Even those who do, and generally have good judgment, will screw up sometimes because they are tired or are working under some sort of time pressure, or something.
Having a policy -- with some flexibility and exceptions allowed -- makes it easier to avoid those sorts of lapses in judgment. And that's a good thing.
But the whole article is just all over the place to me. The author starts by implying that people should be "ashamed" about identifying with a no-Friday-deploy policy, but then softens to the point of saying it's fine to have a personal policy of no late-afternoon deploys, no shipping big changes right before the weekend, etc. But that somehow if that's instead company policy, that's a bad thing. Nope, I don't buy it.
jkingsman|5 months ago
jjice|5 months ago
I've found that little things like that breed a growing resentment and stress that compounds, until someone wants to leave the company. Thursday night outage that I have to hop on? Much smaller deal than a weekend where I have established plans.
One can argue "why was the PR approved in the first place", but sometimes people make mistakes. It especially sucks when there are limited people that know how to troubleshoot and resolve the production issues with a system, even more so when the on-call individual may have not even reviewed the code initially.
All that said - I'd love to deploy as normal on Fridays! I've just found that the type of businesses I've worked at can wait until Monday, and that makes our weekends less risky.
tossandthrow|5 months ago
As an engineer I have absolutely no issue deploying on a friday. But friday bar starts at 4pm, and after that I am not sober before monday.
So leadership don't want me to do it - which is probably wise.
green-salt|5 months ago
banannaise|5 months ago
dogleash|5 months ago
For "read only friday" to have been a novel idea in the first place, you needed a starting point where conventional practice already was making changes live without stopping to consider the time/day of week.
I really suspect the detractors represent a workflow that would break (or at least introduce pain) if unable to push to production for a few days. So they have to give the hard sell on the benefits of continuous deployment.
anonymars|5 months ago
dilyevsky|5 months ago
yacthing|5 months ago
"Deploy on every commit" lmao
"Shipping software and running tests should be fast. Super fast. Minutes, tops." hahah
jidar|5 months ago
kelnos|5 months ago
The idea the author seems to be advocating for is is that, while maybe you sometimes/often shouldn't deploy on a Friday (or even not at the very end of any workday), there should never be a stated policy in place that freezes deployments.
And yeah, I've been at places where they have freezes on weekends, holidays, right around the company's conference, etc. But they're never 100% freezes: if something goes wrong or is necessary, you just get a manager to approve it, and off you go.
I think the author's exhortation that developers should all be able to exercise their judgment to make these calls is a nice idea in theory, but falls flat in practice. Every developer will not always have all the necessary context in order to exercise that judgment. Even those who do, and generally have good judgment, will screw up sometimes because they are tired or are working under some sort of time pressure, or something.
Having a policy -- with some flexibility and exceptions allowed -- makes it easier to avoid those sorts of lapses in judgment. And that's a good thing.
But the whole article is just all over the place to me. The author starts by implying that people should be "ashamed" about identifying with a no-Friday-deploy policy, but then softens to the point of saying it's fine to have a personal policy of no late-afternoon deploys, no shipping big changes right before the weekend, etc. But that somehow if that's instead company policy, that's a bad thing. Nope, I don't buy it.
ForOldHack|5 months ago