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

&quot;Reduces stress: Deploying new code to production can be a stressful experience, especially if it&#x27;s done at the end of the week. By following a &quot;no deployments on Fridays&quot; policy, teams can reduce their stress levels and focus on other tasks.&quot;<p>It would seem more valuable to instead put efforts to make code deploys less &#x27;stressful&#x27;. If you are regularly deploying code and causing huge stress you are doing something else wrong. This reminds me of the old corporate &#x27;you can wear jeans on Friday&#x27;. Somehow wearing them on Friday is ok, but the rest of the time will lead to dispair?

I’m 50&#x2F;50 on this. Then Thursday becomes “omg ship it ASAP” day and Friday becomes firefight Friday.<p>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?”

Here 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.<p>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&#x2F;movies, have dinner, and go back home late.<p>It is not uncommon, in India, to be in offices which are much better than their homes.

If deploying new code is stressful, then here are some tips to try...<p>Improve your deploying until you feel it&#x27;s easy, routine, pipelined, automatic, monitored, tested, and post-deploy tracked so it&#x27;s provably working. Good practical ways to start on this path can include devops, IaC, E2E testing, etc.<p>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.<p>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.

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.<p>The only exception is orgs that need manual QA for regulatory reasons and mobile development, where you follow a weekly&#x2F;bi-weekly cadence because of external Apple&#x2F;Google reviews.

A more general, but less catchy version of the rule is: don&#x27;t do things with a significant probability of requiring an &quot;all hands on deck&quot; response when doing so will be unacceptably slow&#x2F;difficult.

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&#x2F;market making apps), and so your only options are deploy on weekend which means weekend work or on friday afternoon&#x2F;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.<p>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&#x2F;automation.

The engineering week ends at 9 a.m. Monday.<p>So <i>&#x27;I&#x27;ll finish it this week&#x27;</i> means you have until Monday morning.

A company based on doing deploys doesn&#x27;t seem to understand that the goal should be de-risking the deploys, not de-risking your weekends?<p>Charity Majors explains it better than I ever could. <a href="https:&#x2F;&#x2F;charity.wtf&#x2F;2019&#x2F;10&#x2F;28&#x2F;deploys-its-not-actually-about-fridays&#x2F;" rel="nofollow">https:&#x2F;&#x2F;charity.wtf&#x2F;2019&#x2F;10&#x2F;28&#x2F;deploys-its-not-actually-abou...</a>

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&#x27;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.

There are two types of Friday deployments:<p>A) Deploying major changes<p>B) Deploying small changes&#x2F;bug fixes<p>Don&#x27;t do A.

I&#x27;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.<p>Anything coming up at any of these phases would throw it back to development (&quot;fix bug&quot; phase) so we were joking that if we get a P0 critical priority bug on Monday morning and aren&#x27;t done fixing it by afternoon then there&#x27;s no chance in hell it will make it to the deploy on Friday :)

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”.<p>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.<p>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.

I have read in some other post that it’s not about the on-call and development overhead, but the potential operational burden to the company or its customers. What about some bad algorithm which causes millions of dollars in revenue or something blocking your customers over the weekend? Who is going to fix this kind of issues during the weekend? It’s better to deploy on Sundays then.

This article doesn’t come right out and say it but repeatedly suggests working on the weekend is the core problem.<p>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.