The conventional wisdom in our industry is that you do not deploy to production on a Friday. The conventional wisdom is right when your deployment is dramatic. We have spent two years making ours undramatic, and we deploy on Friday afternoons because that is when the people we serve, university IT teams and faculty offices, would prefer we did. The pipeline is the only reason that is true.
The shape of the rollout
Institutions on UMSxLMS share a codebase. They do not share a database, an authentication tenant, a domain, or a deployment cadence. Every institution gets its own isolated tenancy, on UK-resident infrastructure, with a per-tenant feature-flag map and a per-tenant rollback envelope. A release is not a single switch; it is a graph of switches that propagates across the fleet over four days.
The four-day rollout
- › Tuesday, internal canary on the tenants that opted in. Real student traffic, real registrar interactions, full instrumentation, no announcements.
- › Wednesday, extended canary across a handful of tenants chosen for traffic-shape diversity (one research-led, one specialist, one multi-campus).
- › Thursday, staged rollout across the rest, in small batches with a thirty-minute hold between batches.
- › Friday afternoon, release notes published, version pinned, on-call clean for the weekend.
"A release should be the thing your customer notices last, and your operator notices not at all."
What we measure on the way through
Three signals decide whether a batch advances: error rate (any non-recoverable 5xx, or any error class new since the previous build), p95 latency on the application surface, and the management-spine reconciliation rate (every write to the student record produces a confirming read, and the rate of mismatches must remain at zero). Any of those tripping pauses the rollout automatically. The on-call engineer is told the trip happened; they are not asked to prove a negative.
Why Friday
A university IT team is least busy on Friday afternoon. The tickets that would have been raised on a Wednesday morning are fewer; the staff handling them have more time. The argument against Friday deployments is that you create work for a smaller weekend rota. Ours is that we have made deployment so undramatic that the rota does not see a workload spike, and the on-call doesn't lose a Saturday morning.
The thing that is not technical
A boring deployment is mostly cultural. We publish every release note before the deployment ends. We publish the postmortems on the rare occasions we cause an incident. We do not run a private status page. The cultural argument for boring deployments is that the people watching them deserve to be told what is happening; the engineering argument is that the people doing them deserve a Friday evening.