Most teams treat deploys like email: something that can happen at any moment, so it happens at every moment. A hotfix at 11 PM Tuesday. A feature push right before standup Wednesday. A "quick config change" during Thursday lunch. Each one demands attention, context, and a small prayer that nothing breaks.
The result is not speed. It is scattered attention, invisible risk, and a team that never fully exhales.
There is a calmer way to work.
Pick a morning. Saturday works for many small teams because traffic is low and interruptions are rare, but any recurring slot will do. The point is a single, predictable window where all operational work — deploys, reviews, cleanup — happens together.
Not continuous delivery. Not a change freeze. A cadence. A ritual with a start time and an end time, where the team knows exactly what kind of work is expected and can prepare.
Think of it like a weekly farmers market instead of a convenience store. The convenience store is always open, which sounds like a benefit until you realize someone always has to be behind the counter. The market opens once, everything is fresh, and then everyone goes home.
A calm ops window is not just "push code." It has three phases, and the order matters.
Review first. Before anything ships, look at what is already running. Check error rates, queue depths, latency percentiles — whatever your system exposes. The goal is a shared understanding of the current state. You cannot evaluate a deploy if you do not know the baseline.
Deploy second. Batch the week's changes into a single release. Yes, this means features and fixes sit in staging for a few days. That waiting period is not waste — it is soak time. Problems that would have surfaced in production at 2 AM instead surface in a controlled environment during normal hours.
Clean up third. Every system accumulates cruft: stale feature flags, orphaned config entries, temporary workarounds that became permanent. Dedicate the last portion of the window to removing one or two of these. Small, consistent cleanup compounds. Six months later your system is meaningfully simpler, and no one had to schedule a "tech debt sprint."
Context-switching is expensive. Every unplanned deploy pulls at least one person out of whatever they were building. Returning to deep work after an interruption takes far longer than the interruption itself. Five scattered deploys across a week can easily cost a full day of productive building time, even if each deploy only takes twenty minutes.
Batching into one window eliminates that tax. Monday through Friday becomes building time. The ops window becomes ops time. The boundary is clear.
There is a second benefit that is harder to measure but easy to feel: quality becomes visible. When the whole team reviews and deploys together, everyone sees the state of the system. Regressions get caught by more eyes. The person who wrote the code watches it go live and checks the metrics. There is no "throw it over the wall" dynamic because there is no wall — just a shared morning with a shared checklist.
Batched deploys mean slower time-to-production for any individual change. A fix merged on Monday waits until the next window. For teams with hard SLAs on incident response, this is a real constraint.
The honest answer: critical hotfixes still go out when they need to. The window is for planned work. Emergencies break the ritual, and that is fine — as long as emergencies are genuinely emergencies and not just impatience wearing a costume.
If your team ships a "hotfix" more than once a week, the problem is not your deploy cadence. It is your testing, your staging environment, or your definition of critical.
A ritual only works if it is protected. Three things help:
Write a short checklist. Not a runbook that tries to cover every scenario — a one-page list of the steps in order. Review, deploy, clean up. Specific enough to follow, short enough to memorize.
Rotate the lead. One person drives the window each week. They pull up the metrics, narrate the deploy, and pick the cleanup target. Rotating spreads operational knowledge across the team instead of concentrating it in one person's head.
End on time. If the window is two hours, it is two hours. Work that does not fit waits for next week. A fixed endpoint prevents the ritual from expanding into the entire day, which would defeat the purpose.
A team that deploys once a week with full awareness of what is shipping and why will outperform a team that deploys five times a week in a fog of partial attention.
The Saturday morning deploy is not about doing less. It is about doing operational work in a way that lets you see clearly, catch problems early, and then close the laptop knowing the system is exactly where you left it.
For a small team, that might be the most productive habit you adopt.
Be the first to comment.
0 comments
Loading comments...