What a Year of Weekly Releases Taught Us
Shipping every Thursday changed our planning, our testing, and eventually the kind of work we chose to take on.
We used to release when a project was done. In practice that meant every five or six weeks, preceded by a tense week of merging and a weekend somebody lost. Last year we moved to a fixed weekly release, every Thursday at eleven, whether or not anything large was finished.
The mechanics were the easy part. What changed underneath was more interesting.
Small batches change what you are willing to try
When a release costs a week of coordination, only large, certain things are worth putting in it. When it costs nothing, a two-hour experiment can go out on the same day it is written. We ended up shipping far more small improvements, and the small improvements turned out to account for most of the measurable gains.
The size of your release determines the size of your ideas. Make releases cheap and the ideas get braver, not sloppier.
Unfinished work needs a place to live
Weekly releases only work if half-built features can sit in the codebase without reaching users. Feature flags did that for us, and they came with a discipline problem: flags accumulate. We now delete a flag within two weeks of a feature reaching everyone, and the deletion is part of the original ticket rather than a follow-up nobody picks up.
The date is not negotiable, the contents are
The rule that made it stick: the train leaves on time. If your work is not ready, it goes next week. No exceptions, no waiting an afternoon for one more fix. Once the team believed the date was real, the pressure to rush a change in on Thursday morning disappeared, because Friday was only seven days away.
- Fixed day, fixed time, published where everyone can see it.
- Anything not merged by Wednesday afternoon waits.
- A rollback is a normal outcome, not an incident.
- Release notes written by the person who did the work.
Testing moved earlier and got smaller
A weekly cadence makes a long manual test pass impossible, which forced a conversation we had been avoiding. The suite got faster, the flaky tests got fixed or deleted, and the checks that only a human could do got written down as a fifteen-minute list rather than a two-day ritual.
What we would tell a team starting now
Start before you feel ready, and let the process expose the problems. Every reason we had for not releasing weekly turned out to be a description of something that was already broken and simply had not been visible at a six-week cadence.
