[HN Gopher] Why We Ship the Most Code on Friday
___________________________________________________________________
Why We Ship the Most Code on Friday
Author : dban
Score : 15 points
Date : 2023-01-31 22:15 UTC (44 minutes ago)
(HTM) web link (blog.railway.app)
(TXT) w3m dump (blog.railway.app)
| pcdevils wrote:
| Wouldn't it make more sense to count the weekend as a whole? So
| 22 on the weekend, negating the point they're making. All an
| incident on a Sunday says in that data, presumably is, that as no
| one was working no one noticed the issue on the Saturday.
| bradhe wrote:
| Not shipping on Fridays in 2023 is an infrastructure smell.
| pcdevils wrote:
| Infra can make it easier to do it safer; it's not a panacea.
| Sure you can roll back; alert based on metrics / logs / error
| rates, but the knowledge required to automate around these data
| points tends to require the data to already exist, which won't
| be true with new features.
| noman-land wrote:
| To me it seems like just good, clean living. If you have to
| deploy on Friday then you can, but if you don't have to, then
| it just seems like a good idea to do it while many people are
| paying attention instead of over a weekend when most people are
| off.
| marcosdumay wrote:
| Software that is mostly used Monday to Friday doesn't get
| incident reports at the weekend! News at 11!
|
| Deploying when you have low usage has a lot of benefits. But the
| article is convinced that the difference is really because they
| are much better than anybody else.
| boredumb wrote:
| Shipping code on Friday is bad. Shipping things after 4PM is also
| bad.
|
| Why hire any QA? Why code review at all? All of these reduce the
| risk of bad or unintended software being in the wild and not
| releasing on friday or after 4pm reduce the amount of time it can
| be in the wild without harassing people who are otherwise on
| their off time. You can have a half dozen full time QA people and
| a horde of reviewers merging in your request into a staging
| instance that triggers E2E tests that complete and require a
| manager to merge into master to be automatically deployed via the
| same docker image into a cluster and the only guarantees you have
| is that it may be absolutely correct and that it may have an
| issue.
| Hermitian909 wrote:
| Hear hear. Shipping at 10am Monday-Thursday is _heaven_ ,
| almost every single incident requiring immediate attention
| occurs during business hours.
| CobrastanJorji wrote:
| > But following that reasoning, why not also avoid shipping after
| 4PM?
|
| Yes, exactly! Don't ship after 4 PM either!
| fooster wrote:
| Yes, only ship code to production every other Tuesday from
| 10:30-10:30am.
| forgetfreeman wrote:
| Some folks just cannot be satisfied with a warning and have
| to stick the fork in the outlet for themselves.
| lmm wrote:
| I worked somewhere that did that and it was great. Everyone
| knew when the release was. If your code didn't make it into
| this one, well, no worries, it can go out in two weeks' time.
| And if something broke we had all day / all week to fix it.
| throwaway98797 wrote:
| sounds awful for feature velocity
| mikl wrote:
| Is it just me, or wouldn't their `git log | grep...` one-liner
| count commits to all branches that were eventually merged to
| master, not just direct commits to master?
|
| If so, unless they always squash when merging, this just shows
| that they have the most commits on Fridays, not deployments.
| gschier wrote:
| We do squash commits to master, so there's only one commit per
| pull request.
|
| edit: I updated the image caption to specify. Thanks for
| pointing that out!
___________________________________________________________________
(page generated 2023-01-31 23:00 UTC)