Charity Majors explains it better than I ever could. https://charity.wtf/2019/10/28/deploys-its-not-actually-abou...
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.
to your mind, what is the definition of the word "de-risk"?
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.
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.
If you still get days off it can be nice to have them during most peoples work week so you can get errands done easily. As long as it's not consistently every weekend so you can still do weekend things with other people.
It can also be easier to get stuff done on the weekend when most other people/distractions aren't around.
I actually am really happy with how my current team works, where you will be on call during the weekend but only expected to respond to pages so usually you just need to be able to respond and not actually working.. if lots of things page it's even more incentive to improve your systems to not get bugged on the weekend. But even if nothing pages you we still take two days of our choice off the next week.
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 else wrong. This reminds me of the old corporate 'you can wear jeans on Friday'. Somehow wearing them on Friday is ok, but the rest of the time will lead to dispair?
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).
Like you should have for extinguishers even if all precautions have been taken to prevent fire.
They were young, single, and don’t really seem to be those looking out to go to bars, etc. By deploying late, and staying over-time — the company’s rule of “company-sponsored-dinners” after office-time kicks in. They get free dinner, and air-conditioned room which are better than their homes or their room in their shared flats. They anyway ends up watching videos/movies, have dinner, and go back home late.
It is not uncommon, in India, to be in offices which are much better than their homes.
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 capabilities, and self-healing systems. A simple example is to deploy to 1% of people, and when incoming metrics prove success, then increase the percentage.
Success looks like fearless deployments. Some teamwork ideas to try are group ownership, blameless incident responses, causal analysis based on system theory (CAST), service level agreements with stakeholders, and specific software quality attributes for availability, recoverability, and the like.
Plus if you're B2B, your clients are likely mentally checked-out on Friday anyways so they won't even see the new stuff.
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 external Apple/Google reviews.
Of course it can go wrong in either case. But I will keep less slack when the CI is good.
Yes, that means potential weekend work if it goes wrong, and it increases the odds of a bad monday... but both of those can be fixed with good testing/automation.
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.
I think meta had it right: put a little warning on the ship button “it’s after 1pm on Friday, do you really need to ship this now?”
So 'I'll finish it this week' means you have until Monday morning.
A) Deploying major changes
B) Deploying small changes/bug fixes
Don't do A.
Anything coming up at any of these phases would throw it back to development ("fix bug" phase) so we were joking that if we get a P0 critical priority bug on Monday morning and aren't done fixing it by afternoon then there's no chance in hell it will make it to the deploy on Friday :)
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.
