←back to thread

232 points ksajadi | 2 comments | | HN request time: 0.232s | source
Show context
bigmattystyles ◴[] No.45140579[source]
Broke the read-only Friday rule…
replies(2): >>45140943 #>>45141386 #
jkingsman ◴[] No.45140943[source]
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...
replies(10): >>45140998 #>>45141312 #>>45141402 #>>45141439 #>>45141454 #>>45141628 #>>45141856 #>>45142250 #>>45142827 #>>45147202 #
yacthing ◴[] No.45141402[source]
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

replies(3): >>45141484 #>>45142070 #>>45143985 #
sampullman ◴[] No.45141484[source]
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.
replies(1): >>45141654 #
1. yacthing ◴[] No.45141654[source]
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.

replies(1): >>45142051 #
2. da_chicken ◴[] No.45142051[source]
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.