Teams that ship software in irregular bursts tend to share a familiar pattern: weeks of accumulated changes, a stressful release night, a cluster of defects, then a cautious lull before the next big push. A fixed release cadence breaks that pattern by putting releases on the calendar at predictable intervals, so the size of each release shrinks and the process becomes routine. The steps below show how to introduce a fortnightly release train, the most common starting interval, and how to judge whether it is working using evidence from your own pipeline rather than intuition.
Step 1: Measure your current pattern honestly
Before changing anything, collect a baseline. Pull the last six months of production releases from your deployment logs or version control tags and record three things for each: the date, the number of merged changes it contained, and whether it required a hotfix or rollback within a few days. Plot the dates on a simple timeline.
Most teams discover that their releases are clumped, with long gaps followed by several releases close together, and that the large releases are disproportionately represented among those needing fixes. That correlation is the core argument for cadence, and seeing it in your own data persuades colleagues far more than any external article.
Step 2: Choose a release cadence you can sustain
A fortnight is a sensible default for teams moving from irregular releases. It is frequent enough that each release stays reasonably small, and long enough that testing and approval processes do not need to be rebuilt overnight. Teams already releasing weekly may keep that; teams with heavy compliance requirements might start with three or four weeks and tighten later.
The key criterion is sustainability. Pick an interval the team could keep through holidays, staff changes and a busy quarter. A monthly train that never misses is more valuable than a weekly one abandoned after six weeks.
Step 3: Fix the schedule and publish it
Decide the exact day and time of each release, plus the cut-off for changes to be included. A typical fortnightly pattern looks like this:
- Day 1 to Day 8: normal development; changes merge to the main branch behind tests.
- Day 9: cut-off; a release candidate is built from the main branch.
- Day 9 to Day 10: staging verification and sign-off.
- Day 10: production release during an agreed window.
Publish the next six months of dates where everyone, including product owners and support staff, can see them. If you are unfamiliar with the vocabulary, our glossary entries on what a release window means and how a release candidate is defined cover the terms used here.
Step 4: Make the train leave on time, full or not
This is the rule that makes cadence work, and the one most often broken. The train departs on schedule with whatever is ready. A feature that misses the cut-off waits for the next train, which is only two weeks away. Teams that delay a release to squeeze in one more feature are back in burst mode within a few cycles.
Feature flags make this rule easier to follow. Unfinished work can merge to the main branch, switched off, so the codebase does not diverge and the release candidate can be built cleanly on the scheduled day.
Step 5: Automate the repetitive parts
Regular releases expose every manual step, because the same manual step now has to be performed every fortnight. That repetition is useful: it shows exactly where automation pays back. Prioritise in this order:
- Building the release candidate from a tagged commit.
- Running the full automated test suite against it.
- Deploying to staging with the same mechanism used for production.
- Generating a list of included changes from commit history.
- Deploying to production and running smoke checks.
Our longer guide to continuous delivery pipelines and their automation walks through each of these stages with examples.
Step 6: Communicate on the same rhythm
A release cadence is also a communication cadence. After each train, send a brief note to stakeholders: what shipped, what was deferred to the next train, and any known issues. Because the notes arrive on a predictable schedule, people stop chasing the team for status. Some engineering organisations extend this rhythm to public writing, sharing release lessons through a team blog or guest articles. Tools built for contributed articles help here; GuestPostAI, a platform for guest posts, pairs template-based drafting with an editing stage and scheduled publishing directly to a site, which lets those articles appear at an even interval rather than only when someone finds spare time.
Step 7: Rotate who drives the release
If the same engineer runs every train, the cadence depends on one person’s availability, and their knowledge never spreads. Set up a rota so a different team member acts as release driver each cycle, with the previous driver available as backup. The first few rotations will be slower, and that is fine. Within a couple of months, most of the team will have run a release end to end, gaps in the documentation will have been found and fixed, and a holiday or sick day no longer threatens the schedule. Rotation also produces useful evidence: if releases go smoothly only when one particular person drives, the process still relies on undocumented knowledge that needs writing down.
Step 8: Review the evidence after three months
After six or so trains, repeat the measurement from Step 1 and compare. Questions to answer with data:
- Did every scheduled release actually happen? If some were skipped, why?
- Has the average number of changes per release fallen?
- Has the share of releases needing a hotfix or rollback changed?
- How long does a release take from cut-off to production compared with before?
- How do the engineers who run the release describe the experience?
Treat a single good or bad train as anecdote. Look for direction across several. Deployment frequency typically rises steadily as confidence grows, and many teams eventually move from fortnightly to weekly once releases become uneventful.
Common obstacles and how to handle them
Large features that span several trains. Break them into slices that each deliver something testable, or hide them behind flags until complete.
Urgent fixes between trains. Keep a documented hotfix path, but monitor how often it is used. Frequent hotfixes usually indicate that the main train’s testing needs strengthening.
Pressure to delay for one important change. Point to the next train’s date. Two weeks is rarely critical, and holding firm protects the rhythm that makes every later release safer.
Summary
Introducing a release cadence is less a technical project than a scheduling discipline. Measure where you are, choose an interval you can keep, publish the dates, let the train leave on time, automate what repeats and check the evidence after a few months. The outcome is not dramatic. Releases become smaller, quieter and more predictable, and that predictability is exactly what allows a team to improve steadily over time.