Have you ever heard the unwritten rule of engineering: "Don't deploy on Fridays"? Or at the end of the day? It’s a piece of cautionary advice passed down in many organizations, rooted in a legitimate fear that something could go wrong when few people are around to respond, leading to a stressful weekend of emergency fixes.
While the caution is understandable, the rule itself is not a sign of prudence. It's a red flag—a clear symptom of fragile systems, low confidence, and outdated processes. In a modern engineering environment, the day of the week should have no bearing on your ability to deliver value safely.
The Modern Standard: Decouple Deployment from Release
The single most powerful practice that makes Friday deployments safe is the separation of deployment (getting code into the production environment) from release (making that code's functionality available to users).
This is most commonly achieved with feature flags (or feature toggles). New code is wrapped in a conditional block that is "off" by default. This allows you to deploy the new code to production, where it sits dormant and inert. It can be tested internally or by specific user groups without affecting the general user base. The actual "release" is now just the flick of a switch in a control panel, which can be done—and undone—instantly at any time.
This practice turns a high-stakes, monolithic deployment into a low-risk, routine non-event.
The Safety Net: Observability and Fast Rollbacks
Even with feature flags, things can go wrong. The difference in a mature organization is the speed at which they can detect and correct issues. This requires two key components:
-
Robust Observability: This goes beyond simple monitoring. It means having systems in place (like detailed logging, tracing, and metrics) that allow you to quickly ask questions about your system's state and understand why something is happening, not just that it's happening. Good observability can detect anomalies caused by a new release almost immediately.
-
Solid, Automated Pipelines: Your CI/CD pipeline should be a source of confidence. If a problem is detected, you should be able to trigger a rollback to a previous stable version with the push of a button. Whether it's reverting using build artifacts or switching traffic in a blue/green deployment, the process should be fast, reliable, and tested.
Deploy Anytime with Confidence
When you combine the practice of decoupling deployment from release with the safety net of strong observability and easy rollbacks, the "don't deploy on Friday" rule becomes what it truly is: an ancient relic.
Modernizing these aspects of your engineering practice isn't just about being able to deploy on a Friday. It's about building a resilient, high-trust system that allows you to move faster, safer, and deliver value to your customers at any point in time that you choose.