Do not deploy on Friday!
Ok… but why not?
After several days of work, my ticket was finally ready to be deployed in production. It was not a difficult task to develop and the code review was quick.
First feedback happened during the UI review: the margins weren’t precise, some elements were not well-centered, some font sizes were inaccurate… It was just a few pixels, and our designers keep their eye on everything.
These concerns fixed, the ticket made it to the QA team. Nothing gets by our testers; they are formidable.
And lo and behold, they found something wrong: a weird issue about unsynchronized data when the user types too quickly on the keyboard. To find this type of wacky bugs, our testers must not be real humans but rather a kind of robots…
Long story short, I managed to correct their feedback. My ticket is now a click away from being deployed in production… but something is wrong.
It’s Friday.
An old belief persists among developers: deploying a Friday would bring bad things. The most insignificant of tickets could cause the application to crash if deployed on a Friday.
There are countless stories of inaccessible sites, shameful developers, and wasted weekends because of a task put into production on a Friday. Naturally, the gold rule of development came to be:
Do not deploy on Friday!
So my ticket ready, validated by the entire team, but an old legend prevents me from totally complete it.
In addition, today is the end of the sprint; this task is the last of my board. If I pass it, I will have finished my sprint!
It’s a shame to postpone deployment when we’re sure everything works perfectly…
Then I remember that some developers are a little less strict on this rule: they tolerate deploying on a Friday morning. If there are any problems, we have the whole day to fix it.
Galvanized by this reflection, I’m about to click on the button… but something is wrong.
It’s 4:34pm.
The morning has come and gone…
So what do I do? Give up? I just leave the ticket for Monday?
It feels like an admission of weakness, doesn’t it?
When we refuse to deploy on a Friday, it is because we are afraid that an accident will happen. We fear that an unforeseen bug will occur.
In short, it’s because we are not 100% sure of our application’s behavior.
Nowadays, most tech companies have a continuous integration system to ensure a reliable and robust product.
OpenClassrooms is no exception to the rule:
- Unit tests are automatically run.
- Our colleagues perform reviews at every stage of a task’s life, code ones or design ones.
- We have staging environments replicating our production environment.
- Functional tests ensure that nothing is broken.
- Even if a bad surprise comes after the deployment in production, we just have to click on a single button to go back.
What’s the point of having all of this if, in the end, we follow our gold rule of never deploying on a Friday?
Refusing to deploy into production on Fridays indicates a lack of confidence in the workflow.
Does your team refrain from deploying at the end of the week? Is this a subject of endless debate? It’s because you have a problem in your workflow. Having confidence in your system is the key.
As far as I’m concerned, I have confidence. So on this Friday, May 10th, 2019, I click on this button, even if it is now 4:35pm.
Well, I have to admit that I have slightly romanticized this deployment. The reality is that I did not hesitate a single second to deploy this task.
Moreover, none of my colleagues have this kind of hesitation: at OpenClassrooms, we trust our tools. We deploy several times a day, whatever the time of the day, and even on Friday!
So cursed Friday is not a reality here, and it should not be anywhere.
What about you? Have you managed to get rid of this Fridayphobia?
