A computer upgrade shut down BART

Broke the read-only Friday rule…

I know this is a tongue in cheek casual comment, but this article is a really good and important counterpoint: https://charity.wtf/2019/05/01/friday-deploy-freezes-are-exa...

It is not about fear, it is about risk management.

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.

I enforce a work/life balance and this is how the team loses a weekend when something goes wrong.

Wait... (Obligatory) Did they forget to mount a scratch monkey?

This reads like someone who works on a small and simple system.

"Deploy on every commit" lmao

"Shipping software and running tests should be fast. Super fast. Minutes, tops." hahah

this is just mindless blogospam/clickbait/"buy my thing" - the author even admits shipping big changes on friday is a bad idea

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.

Deploy to what? Staging on every merged PR (commit to stg), and prod deploy on every commit to main? That sounds reasonable to me, and I've done some variation of it on most projects for the last 10 years or so without issue.

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.

Well people aren't talking about not deploying to staging on Fridays.

And there are hints to what the author actually means, like "Each deploy should be owned by the developer who made the code changes."

That just isn't feasible in a system that's of any reasonable size.

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.

Yeah, what happens when Team A makes a change and Team B makes a different, seemingly unrelated change, and they both get merged and pushed... only to have a dozen customers discover that if someone is using Feature X that Team A just worked on and Feature Y that Team B just worked on while they have Uncommon Option Q enabled, then their backend process server will crash taking down their entire instance.

Who's fault is that?

Asking because I have been the customer with Uncommon Option Q enabled.

> "Shipping software and running tests should be fast. Super fast. Minutes, tops." hahah

You mean to tell me not everyone works on some SaaS product outside of critical path?

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?

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.

Charity's been running honeycomb.io, a SaaS startup with millions of dollars of revenue, for 9 years now, after being an early-stage engineer at Parse, a mobile backend-as-a-service startup that powered half a million mobile apps. She's talking about what she's made a reality at her company and its clients.

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.