Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No deployments on Fridays: A good practice for software development teams

deploybot.com

Post reply on HN
Print view View original

11–20 of 34 posts

Re: No deployments on Fridays: A good practice for software development teams

#11

Post by PretzelPirate »

StayTrue wrote: post #9

This article doesn’t come right out and say it but repeatedly suggests working on the weekend is the core problem. I like Friday releases because I don’t care about working weekends. In my mind slower uptake from weekend users can help identify problems before major uptake Monday morning. Although that’s theoretical because it hasn’t mattered in practice.

> I don’t care about working weekends.

This seems like a take I don't hear often. I won't work on a weekend unless the service is on fire and I'm the only one who can save it (which means I've done a bad job).

I'm fine with Friday deployments as long as we have a good release pipeline with multiple stages of validation and slow rollout, but if I see that my team is having to regularly work weekends because we deploy Friday, I'll stop deploying and respect their time.

Re: No deployments on Fridays: A good practice for software development teams

#13

Post by zbentley »

sponaugle wrote: post #5

"Reduces stress: Deploying new code to production can be a stressful experience, especially if it's done at the end of the week. By following a "no deployments on Fridays" policy, teams can reduce their stress levels and focus on other tasks." It would seem more valuable to instead put efforts to make code deploys less 'stressful'. If you are regularly deploying code and causing huge stress you are doing something el…

That's fair, but easier said than done. Reducing the stress/risk of deploys is a long, hard process at the best of times, and also is something that you have to continue doing in perpetuity as the complexity/failure impact of the systems being deployed grows. It's also an area where many organizations struggle to (re)commit resources appropriately.

If you ever find yourself behind the curve in that area (as in: deploys are risky and stressful events), then a good short-term mitigation for the symptoms might be to avoid deploys on Fridays or similar, while also committing resources towards improving the root cause (deploys suck).

Re: No deployments on Fridays: A good practice for software development teams

#14

Post by jaysinn_420 »

A company based on doing deploys doesn't seem to understand that the goal should be de-risking the deploys, not de-risking your weekends?

Charity Majors explains it better than I ever could. https://charity.wtf/2019/10/28/deploys-its-not-actually-abou...

Re: No deployments on Fridays: A good practice for software development teams

#15

Post by JohnFen »

jaysinn_420 wrote: post #14

A company based on doing deploys doesn't seem to understand that the goal should be de-risking the deploys, not de-risking your weekends? Charity Majors explains it better than I ever could. https://charity.wtf/2019/10/28/deploys-its-not-actually-abou...

You can't "derisk" deploys, you can only reduce the amount of risk they incur. Not deploying the day before a nonwork day remains solid advice.

Re: No deployments on Fridays: A good practice for software development teams

#16

Post by JohnFen »

StayTrue wrote: post #9

This article doesn’t come right out and say it but repeatedly suggests working on the weekend is the core problem. I like Friday releases because I don’t care about working weekends. In my mind slower uptake from weekend users can help identify problems before major uptake Monday morning. Although that’s theoretical because it hasn’t mattered in practice.

If I'm working on a weekend, it's because the world is on fire. There is no other reason I'd be willing to give up precious personal time for an employer.

Re: No deployments on Fridays: A good practice for software development teams

#17

Post by bananapub »

JohnFen wrote: post #15
jaysinn_420 wrote: post #14

A company based on doing deploys doesn't seem to understand that the goal should be de-risking the deploys, not de-risking your weekends? Charity Majors explains it better than I ever could. https://charity.wtf/2019/10/28/deploys-its-not-actually-abou...

You can't "derisk" deploys, you can only reduce the amount of risk they incur. Not deploying the day before a nonwork day remains solid advice.

> You can't "derisk" deploys, you can only reduce the amount of risk they incur.

to your mind, what is the definition of the word "de-risk"?

Re: No deployments on Fridays: A good practice for software development teams

#18

Post by JohnFen »

bananapub wrote: post #17
JohnFen wrote: post #15

Earlier quoted context omitted.

You can't "derisk" deploys, you can only reduce the amount of risk they incur. Not deploying the day before a nonwork day remains solid advice.

> You can't "derisk" deploys, you can only reduce the amount of risk they incur. to your mind, what is the definition of the word "de-risk"?

Reducing the risk of a deployment that catches fire.

Re: No deployments on Fridays: A good practice for software development teams

#19

Post by jitl »

JohnFen wrote: post #15
jaysinn_420 wrote: post #14

A company based on doing deploys doesn't seem to understand that the goal should be de-risking the deploys, not de-risking your weekends? Charity Majors explains it better than I ever could. https://charity.wtf/2019/10/28/deploys-its-not-actually-abou...

You can't "derisk" deploys, you can only reduce the amount of risk they incur. Not deploying the day before a nonwork day remains solid advice.

Your response sounds like “you can’t derisk deploys, you can only derisk deploys”

Re: No deployments on Fridays: A good practice for software development teams

#20

Post by redserk »

jph wrote: post #6

If deploying new code is stressful, then here are some tips to try... Improve your deploying until you feel it's easy, routine, pipelined, automatic, monitored, tested, and post-deploy tracked so it's provably working. Good practical ways to start on this path can include devops, IaC, E2E testing, etc. Then get good at tactics such as rainbow rollouts, blue-green, canaries, feature flags, dark launch, self-throttling…

Ideally this is where everyone ought to be anyways. In a vacuum, all of these would stop bad deployments in theory. But in practice, no amount of prep can address and prevent every potential way a deployment can go sideways.

Plus if you're B2B, your clients are likely mentally checked-out on Friday anyways so they won't even see the new stuff.

Post reply on HN