On a Monday afternoon, I found myself attending a calendar event titled “Deployment Session.” I was curious about the purpose of the meeting. The team’s response was clear: “we don’t deploy on Friday, unless it’s urgent or a bug fix.”
They don’t deploy on Fridays. They were afraid of their weekends being disrupted by the application crashes. Also, they also didn’t want to disappoint customers by not being responsive.
Those are the fair points. In fact, “No Deploy Fridays” becomes the golden rule for many development teams.
Is “No deploy Fridays” a Problem?
OpenClassrooms, an online education platform, invested heavily in unit tests, peer reviews, staging environments, functional tests, and single-click rollback mechanism. They built a robust continuous integration system to prevent application crashes and recover from any incidents.
Despite this, Adrien, a frontend developer in OpenClassrooms, went through a series of thoughts before deciding to deploy on Friday afternoon.
Although we may have potential solutions for “No Deploy Fridays”, their impact on developers’ psychology remains a subject of consideration.
The Real Cost
“No Deploy Fridays” may offers a peaceful weekend, it comes at a significant cost. For instance, imagine having a feature is thoroughly tested and ready for deployment on a Friday, only to postpone it until Monday.
This delay results in:
Users waiting an additional three days before they can benefit from the feature.
If your users are most active on weekends, this delay also means valuable feedback is delayed by a week, potentially hindering business growth for months.
For a feature generating $50k per day, the cost of such a delay amounts to $150k.
I am not saying that developers don’t deserve peaceful weekends, but the real cost of avoiding deployment on Fridays is much higher than you may have thought.
If the scenarios above do not apply to your specific situation, the mental well-being of your developers alone may justify exploring alternative solutions.
The Two-Steps Solution
Having encountered the same challenge in two development teams, I implemented a consistent solution that significantly improved delivery confidence and business agility.
The solution involves two steps, decouple deployment and deploy early often.
Step One: Decouple Deployment
Big bang release is the most common software delivery technique. When a deployment went out, the new code changes released to the users simultaneously.
Deploy is an activity of putting the new code changes in a specific environment (in this case, production environment). Release is an activity of making the new code changes available to the users. Decoupling deployment means the separation of these two activities.
With the decoupling, your developers gain confident in deploying on Friday when they know the users are not impacted.
How to do it? Use feature flags (aka feature toggles).
Feature flagging is a powerful technique that allows modifying system behavior without changing code. The first step of the solution is leveraging the release flag. By incorporating a conditional statement within the code, such as:
if (flag_is_on) {
// code_changes
}
This technique requires practice and familiarity. Initially, implement it two to three times within your team. As your team becomes comfortable with the approach, you can progress to the next step.
Learn From Experience
My team made a mistake when first adopted the technique.
We were replacing a legacy API. The new API accepted a different set of parameters. We modified the frontend code and added a feature flag there. When we deployed it, we hadn’t released the feature but the applications started crashing.
Although the new change didn’t expose to the users, but the backend was calling the new API without the necessary parameters.
We added a feature flag on the frontend but missed it on the backend. The call to the new API was executing regardless the status of the feature flag.
In this article, you can find more implementation techniques.
Step Two: Deploy Early Often
Now, the deployment is decoupled from the release. The development team has restored their confidence in deployment. This step strengthens the confidence.
When working on a complex feature, it is broken down into smaller pieces. Multiple deployments up to the single release. Feature branching is the common practice when the team is practicing big bag release.
However, the decoupled deployment changes the way of working.
Without the concern of affecting users, the team can start deploying the smaller pieces before everything is ready.
If there is any problems with the new code changes, it can be identified early and the solution will be easier.
Enabled Parallel Development
My team discovered the benefits of enabling parallel development in our journey.
In the old way of working, when creating a new application page, the team would break it down into multiple sections and work on them sequentially. This approach resulted in a month of development time.
However, in the new way of working, the team started with a skeleton application page, which was protected by the feature flag. Each team member then picked up a different sections and developed them in parallel. This change allowed for concurrent development, significantly reducing the overall development time to just two weeks.
Conclusion
Unintentionally, “No Deploy Fridays” is taking a toll on developers’ mental well-being. While modern tooling and techniques can help reducing the associated risks, addressing the issue from a psychology standpoint is crucial.
The Two-Steps Solution—decouple deployment and deploy early often—restores and strengthens the developers’ confidence in software delivery.
Deploy or not is not a question anymore. Deploy becomes the default option. By leveraging feature flags, development teams can overcome the limitations of “No Deploy Fridays” and embrace a more agile and efficient software delivery process.
Remember, the goal is not to compromise developers’ well-being, but rather to strike a balance between their needs and the overall success of software delivery.