No deployments on Fridays: A good practice for software development teams
1–10 of 34 posts
Re: No deployments on Fridays: A good practice for software development teams
#2[deleted]
Re: No deployments on Fridays: A good practice for software development teams
#3I 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 friday is THE day to do a release.
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.
Re: No deployments on Fridays: A good practice for software development teams
#4I’m 50/50 on this. Then Thursday becomes “omg ship it ASAP” day and Friday becomes firefight 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?”
Re: No deployments on Fridays: A good practice for software development teams
#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 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?
Re: No deployments on Fridays: A good practice for software development teams
#6If 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 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.
Re: No deployments on Fridays: A good practice for software development teams
#7For 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 external Apple/Google reviews.
Re: No deployments on Fridays: A good practice for software development teams
#8I'm half joking here but at one of my past workplaces, the development process was something along: fix bug, get reviewed, pull request tested by QA, integrate, retest after integration, run in UAT and only then eventually deploy to production.
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 :)
Re: No deployments on Fridays: A good practice for software development teams
#9This 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.
Re: No deployments on Fridays: A good practice for software development teams
#10Here is a different story from another perspective of a niche group of team. I led a few teams — small groups for each project. I realized that quite a few of the team have a strange habit of deploying around 5-6PM on Fridays! What I found out was interesting.
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.