Deploy on Friday: shattering the myth of the Friday curse

If you work on the Web, you've probably already heard this phrase thrown out in the middle of a discussion

It's like an unspoken rule, a bit like not combining socks and sandals.

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.

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.

Are you paranoid about deploying on a Friday? Here are a few symptoms to prove it.

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.

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.

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?

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.

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.

All too often, production releases are made sacred. It's made into a special and unique event. It's not really

Worse still, production releases are planned several weeks in advance and have to be carried out outside office hours - the famous 8pm Tuesday release.

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!

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

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.

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.

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!).

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.

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.).

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.

So take the time to document everything that can be documented:

And above all, don't forget to test your rollback procedure regularly to make sure everything is up to date.

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.

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?

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

ChatGPT (2023)
https://chat.openapi.com

Midjourney (2023)
https://midjourney.com