The Art of the ‘Read-Only Friday’: Why we don’t deploy before the Weekend

The Art of the ‘Read-Only Friday’: Why We Don’t Deploy Before the Weekend

In the high-stakes world of systems administration and DevOps, few unwritten rules are as sacred as the “Read-Only Friday.” While it may sound like a relaxed policy, it is actually a strategic defensive measure designed to ensure stability, reliability, and sanity for the engineering team. As the saying goes: “Don’t deploy on a Friday unless you plan on spending your weekend in the office.”

The Philosophy of Stability

The core objective of any production environment is uptime. When we deploy code or infrastructure changes, we introduce variables. Even with robust CI/CD pipelines, automated testing, and canary releases, unforeseen edge cases can trigger failures once the change hits real-world traffic patterns. By restricting deployments to Monday through Thursday, we guarantee that the team is fully staffed, alert, and capable of addressing incidents during standard business hours.

The Human Factor

Systems administration is as much about human performance as it is about server performance. A “Read-Only Friday” respects the work-life balance of the SRE and DevOps teams. An incident occurring at 2:00 AM on a Saturday morning results in exhausted engineers, longer mean-time-to-recovery (MTTR), and an increased likelihood of human error during remediation efforts. By avoiding late-week deployments, we ensure that everyone remains well-rested and prepared to handle the unexpected.

Establishing a ‘Read-Only’ Guardrail

Enforcing a policy like this is easier when integrated into your workflow tools. Whether you use GitLab, GitHub, or Jenkins, you can implement checks to prevent deployments outside of your designated window. Below is an example of a simple shell script check that could be integrated into a pre-flight deployment hook:

#!/bin/bash
DAY=$(date +%u)
HOUR=$(date +%H)
# 5 is Friday
if [ "$DAY" -eq 5 ]; then
echo "Deployment blocked: It is Read-Only Friday."
exit 1
fi
# Additional logic for cutoff hours on Thursday
if [ "$DAY" -eq 4 ] && [ "$HOUR" -ge 16 ]; then
echo "Deployment blocked: Cutoff time reached for the week."
exit 1
fi
echo "Environment is safe for deployment."
exit 0

Exceptions and the ‘Emergency’ Mindset

Every rule has exceptions. If a critical security vulnerability (CVE) is discovered, or if production is currently experiencing a catastrophic outage, the “Read-Only Friday” rule is superseded by the need for immediate remediation. However, these instances should be treated as exceptions, not the norm. By maintaining a strict protocol for normal operations, you ensure that when an actual emergency happens, the team is focused and not dealing with the fallout of a non-critical Friday afternoon patch.

Conclusion

The “Read-Only Friday” is not about laziness; it is about risk management. By aligning our release schedule with our team’s availability, we create a more resilient infrastructure and a healthier work culture. Respect the weekend, avoid the Friday deploy, and keep your systems running smoothly.