Deploy on Friday: shattering the myth of the Friday curse

Auteur(s) de l'article

If you work on the Web, you've probably already heard this phrase thrown out in the middle of a discussion
No production release on a Friday!
It's like an unspoken rule, a bit like not combining socks and sandals.
Two socks one making fun of the other one
What if Fridays weren't to blame? Let's sort this out once and for all.
The customer is rarely the one to impose this rule, it's more a kind of mantra in the dev teams.
And frankly, nobody wants to be called in at the weekend to fix a bug because of a messy production run.
At least once, we've all had a problem with a prod on a Friday afternoon...
But let's be honest, not deploying on a Friday means treating the symptoms without tackling the disease.
Refusal to deploy on certain days often hides deeper problems.
So let's put on our best surgical gloves and examine - together - each of these symptoms one by one.

An insidious ailment

Are you paranoid about deploying on a Friday? Here are a few symptoms to prove it.
Release roulette
The first symptom is often the absence of a reliable, automated deployment system.
Or worse, a system that is partially manual, not documented at all and totally out of kilter.
As a result, deployment takes an inordinate amount of time and requires a superhuman brain.
What if Fridays weren't to blame? Let's sort this out once and for all.
And the worst thing is, if something goes wrong, it's hard to get back to the pre-release state without tearing your hair out.
Evil regression
One of the great classics of catastrophic deployments is the lack of testing of the latest release.
Whether due to budgetary constraints or time constraints, no-one has had the opportunity to put in place a solid battery of tests. As a result, you run the risk of ending up with bugs and regressions, no matter how far-fetched.
If something goes wrong, you have to be prepared to drop everything and fix it in a hurry.
And Friday afternoon isn't the best time for that, is it?
What if Fridays weren't to blame? Let's sort this out once and for all.
Too big to unfail
The longer you delay going live, the more changes you create. And the more changes you have, the more you're afraid of crashing the whole thing when you go into production.
In other words, it's like trying to fit everything into a pair of size 34 SlimFit jeans when you've put on a few kilos over the last Christmas. There's a risk of cracking on all sides.
It's perfectly normal to have fears. It's mathematical: the bigger the changes, the more risks and side effects there are.
Rollback hell
When everything goes wrong, the simplest solution is a rollback, i.e. restoring the system to its pre-release state.
But let's be honest, we often don't know how this works and it creates a bit of panic. Sure, it's not very reassuring to deploy without knowing how to roll back if things go wrong.
Of course, having to trigger a rollback is never very glorious, but at least it will allow you to get your project back on track quickly and postpone the production launch for valid reasons.
Unfortunately, this procedure is often neglected. Either the system doesn't work properly, or it hasn't really been tested or relaunched recently. Adding even more stress to our natural fear of deployments.
Sacralisation
All too often, production releases are made sacred. It's made into a special and unique event. It's not really
What if Fridays weren't to blame? Let's sort this out once and for all.
Worse still, production releases are planned several weeks in advance and have to be carried out outside office hours - the famous 8pm Tuesday release.
Diagnosis
  • To sum up, there are a number of problems that can be identified:
  • No automatic deployment system
  • Insufficient battery of tests
  • Too many changes between two production releases
  • Scruffy rollback system
  • Sacralisation of the event
    And because we're afraid to deploy, we rarely do, so we don't know the deployment process very well, which means the problem spreads even faster.
    It's a vicious circle!

    Treating evil

    So doctor, is it serious?
    It's up to you to decide how serious it is, but it's certainly not catastrophic, and fortunately it's treatable!

    Deploy often & with Ease

    First of all, I strongly advise you to set up a Continuous Deployment tool. Yes, that's the basis!
    Whether you opt for an in-house tool or a tried-and-tested system like Capistrano, the important thing is to have confidence in your tool. Otherwise, you risk going through hell every time!
    Personally, we systematically use Capistrano in our Github Actions for all our projects.
    We deploy our Symfony projects with Capifony and our Drupal projects with CapDrupal.
    We have also created our own recipes for WordPress and NextJS projects.
    There's no such thing as a perfect tool, it's up to you to find yours and build your ecosystem around it.
    If you want to avoid ending up with a mountain of gargantuan changes, you need to deploy often (thanks to continuous deployment) and keep a CHANGELOG.md of your changes up to date.
    Do one thing, and do it well

    UNIX philosophy

    At Antistatique, we've adopted the Keep a Changelog format, which allows us to announce all changes to our customers - at each release - and to keep an eye on the exact content of our production releases, without having to dig through the Git history.
    What if Fridays weren't to blame? Let's sort this out once and for all.
    Tests everywhere
    You're going to have to get your hands dirty! But don't worry, it's not insurmountable.
    To avoid regressions, you need unit tests and functional tests.
    Unit tests will enable you to ensure that the code you have written conforms to your expectations, without regression or error.
    As for functional tests, there are several solutions depending on what you want to test. But basically, they allow you to make sure that your application works as intended for the user.
    Personally, I like the Behat or Cypress tools for purely functional tests.
    For unit tests, we mainly use PHPUnit and Panther (yes, even for WordPress!).
    Daily Routine
    Going live shouldn't be an event of apocalyptic proportions. It's important to plan ahead, but it shouldn't turn into a psychodrama either.
    What if Fridays weren't to blame? Let's sort this out once and for all.
    The more you do, the less stressful it is. And if you release more often, you'll have fewer things to test each time, so less risk of breaking everything. THAT'S ALL THERE IS TO IT.
    With us, we deploy every day. We don't really have any rules or conditions for not deploying. With the exception of special customer events. Like, for example, a press conference for one of our customers or a demo, where the slightest down-time (site inaccessible, which is generally a few minutes during a production launch and can extend to several minutes in the case of a rollback) would be unacceptable.
    We also sometimes refuse to go live when the team in charge of the project is simply not present (due to holiday, illness, etc.).
    Trust your Rollback
    We all know that deployment failures can happen, even to the best of us. So here's my best advice: automate everything that can be automated and document the rest.
    Let's face it, not everything can be automated.
    So you need to document the steps clearly and precisely.
    I assure you, when the system is down and you're in panic mode, you'll be glad to have a step-by-step procedure at hand.
    It'll save you the trouble of having to think things through when you're already in survival mode.
    What if Fridays weren't to blame? Let's sort this out once and for all.
    So take the time to document everything that can be documented:
    • Where are the backups located?
    • How do you mount the database on the production server?
    • How do you put the previous release back into production?
    • What commands need to be run to remount the server?
    • Where is the server located and who are the emergency contacts?
      And above all, don't forget to test your rollback procedure regularly to make sure everything is up to date.

      Conclusion

      What if Fridays weren't to blame? Let's sort this out once and for all.
      You need to know how to prepare the ground in advance. Having a good deployment strategy and effective tools will enable you to deploy with confidence and peace of mind, even on a Friday at 5pm. You also need to have an effective and functional recovery procedure.
      Once these tools are in hand and under control, your production launches will be Finger in the Nose. In the worst case, a rollback and you take the time to understand what has just happened.
      We need to break the vicious circle that only increases the frequency of deployment, risk and loss of confidence.
      And if your customers are still reluctant, simply tell them, "We can do it, but we'll bring pizzas and beer just in case!" 😜🍕
      What about you, what do you say to your customers when they ask to deploy to production on a Friday?

      Source

      Yves Brissaud (Mar 2013) Ne pas pousser en prod le vendredi. FAUX !
      http://log.winsos.net/2013/03/12/ne-pas-pousser-en-prod-le-vendredi-faux.html
      Ruby K V (Déc 2021) Fear Of Production Deployment — A Never-Ending Tale?
      https://www.linkedin.com/pulse/fear-production-deployment-never-ending-tale-ruby-k-v/
      Alessandro Minoccheri (Jan 2021) Why you should deploy on Friday without fear
      https://medium.com/flowingis/why-you-should-deploy-on-friday-without-fear-80a26d3c17c1
      Kyrylo Yefimenko (Déc 2020) The Fear of Deployment Factor
      https://engineering.talkdesk.com/the-fear-of-deployment-factor-48cf09095f16
      Mark Levy (Avr 2022) How to Deploy Code Without Fear
      https://www.opsmx.com/blog/how-to-deploy-code-without-fear/
      Steve Ardalis (Mar 2022) Deploy More Often
      https://ardalis.com/deploy-more-often/
      Candost Dagdeviren (Déc 2021) Why should you deploy your code in smaller chunks and release software often?
      https://candost.blog/why-should-you-deploy-your-code-in-smaller-chunks-and-release-software-often/
      Matt Rickard (Oct 2022) Deploy Early, Deploy Often 
      https://matt-rickard.com/deploy-early-deploy-often
      Cédric Hulin (Mar 2022) Ne déploie pas en production un vendredi !?
      https://www.linkedin.com/pulse/ne-d%C3%A9ploie-pas-en-production-un-vendredi-c%C3%A9dric-hulin
      Aurone (Juin 2022) La mise en production du vendredi à 17h
      https://www.aurone.com/blog/la-mise-en-production-du-vendredi-17h/
      @PasLeVendredi (2023) Votre rappel hebdomadaire que les mises en prod le vendredi, c’est interdit.
      https://mobile.twitter.com/paslevendredi
      Est-ce qu’on met en prod aujourd’hui? (2023)
      https://www.estcequonmetenprodaujourdhui.info
      Midjourney (2023)
      https://midjourney.com