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

21–30 of 34 posts

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

#21

Post by JohnFen »

jitl wrote: post #19
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.

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

I was unclear, or perhaps I misunderstood the comment I was replying to. I read it as "deploying on Fridays isn't a problem if you derisk the deploys".

My response was that you can't derisk deploys to the extent that Friday deployments are good practice.

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

#22

Post by jitl »

This reads like super low effort blogspam. Seeing this advice from a deploy vendor makes me think, “these people must not be serious about their product”.

If your deploys break a lot, fix your testing and deploy process! Then you’ll have much lower stress every day of the week, instead of low stress on Friday and high stress every other weekday.

At least figure out how to make rollback super quick and easy. Then at least if something goes wrong at 11am when you’re rolling out the Friday deploy, you can roll back and be stress free again by 1pm.

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

#23

Post by jitl »

JohnFen wrote: post #21
jitl wrote: post #19

Earlier quoted context omitted.

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

I was unclear, or perhaps I misunderstood the comment I was replying to. I read it as "deploying on Fridays isn't a problem if you derisk the deploys". My response was that you can't derisk deploys to the extent that Friday deployments are good practice.

Maybe you can’t derisk deploys on Friday, but we’ve derisked them just fine, and are eager to deploy more frequently Friday and every other day or the week - right now we do once per day, looking forward to continuous delivery to production.

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

#24

Post by redserk »

anthonyskipper wrote: post #3

I get the point here but for many organizations and types of companies this is a terrible and unworkable idea. A lot of companies have to wait till weekend for maintenance (e.g. trading/market making apps), and so your only options are deploy on weekend which means weekend work or on friday afternoon/evening. Once week starts there are no good times to do a release. So for a vast number of super critical systems frid…

I think it depends entirely on who the end user is.

It's completely understandable in situations where there is no allowable downtime except the weekend.

But if it's a SaaS product to categorize sticky notes... probably not worth risking ruining a Friday.

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

#25

Post by jaysinn_420 »

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.

Sure, you can't remove all risk, but you can reduce it and reduce the risk of unexpected firefighting work. You can implement rolling or blue/green deployments that roll-back on failure. The key is being able to identify failures, which means having meaningful canaries to identify issues. Those canaries can also improve your operational awareness so they aren't just a deployment investment.

If you don't deploy on Friday then you lose 20% of your deploy opportunity. If you only deploy once or twice a week, then sure - choose Monday/Wednesday or something, but if you deploy more frequently then improve your deployment safety.

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

#28

Post by hooverd »

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"?

Remove the risk.

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

#29

Post by wryoak »

One of my last employers did this and I begged them to just let a couple people work a five day schedule that included Saturday and or Sunday (I wanted to be one of those people) so we could deploy any day, trouble shoot any day, but they were against it. I think people need two (actually at least three, but that's a different discussion) days off every week, but I also don’t think people need to work identical schedules. Put another way: you must give the castle guards a break from staving off attacks but you must not give them all the same break.

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

#30

Post by lolc »

cheeseface wrote: post #7

For software orgs deploying web services, ”no deployments on Fridays” should be seen as a temporary workaround, not a best practice to follow. It is a symptom of poor automatic QA processes (linting, automatic tests, etc.) and lack of capabilities like feature flags. The only exception is orgs that need manual QA for regulatory reasons and mobile development, where you follow a weekly/bi-weekly cadence because of ext…

Exactly! It really depends on the setup. Good CI? Deploy at will. Nonexistent CI? Tuesday morning.

Of course it can go wrong in either case. But I will keep less slack when the CI is good.

Post reply on HN