Improving Release Process: From Two‑Week to One‑Week Sprints and Holiday Moratorium

Background

In the past, software releases often took months or even years, but with the rise of agile development the release cadence has shifted to weeks or even shorter intervals.

Two‑Week Sprint Process

The team originally followed a two‑week sprint (Sprint) cycle. Planning meetings were held in Jira, development was done on feature branches, code was merged via pull requests after review and automated tests, and a tag was created for testing. The last two days of the sprint were a code‑freeze on the master branch, after which a release tag was deployed to production.

Switching to One‑Week Sprints

To increase release frequency, the team moved to a one‑week sprint. While this allowed faster delivery, they quickly observed a drop in quality, more post‑release incidents, and frequent last‑minute changes that were hard to control.

Holiday Readiness and Moratorium

During high‑traffic holiday periods the team introduced a "Soft/Hard Moratorium"—no new features were deployed, only critical bug fixes and patches, with strict approval processes. A dedicated holiday branch was used for these changes and tested for a week before production deployment, resulting in markedly higher stability.

Root Causes of Instability

1. No Stable Release Branch

Releases were always based on the master branch, which continuously received new features and bug fixes, making it inherently unstable, especially under a one‑week cadence.

2. Insufficient Testing Time

Two‑week sprints allowed 3‑5 days of testing; one‑week sprints reduced this to 1‑2 days, leading to many defects surfacing only after release.

Process Improvements

Stable Release Branch per Sprint

After each sprint a dedicated release branch is created; only critical bug fixes are merged into it, while new features continue on master.

Allocate Adequate Testing Time

The team staggered releases: the first sprint’s code stays in a test environment for a week while the second sprint is being developed, then the first sprint is released, and the second sprint undergoes a week of testing before its release.

Handling Parallel Sprints and Multi‑Branch Management

Running two sprints in parallel introduces extra coordination, but the team found the overhead manageable. Bug fixes may need to be merged into multiple branches (holiday, release, master), which is acceptable given the stability gains.

Visibility Tools

Custom dashboards were built to show the current version in development, testing, and production, helping both internal and external stakeholders understand the release status.

Comparison with Chrome Release Cycle

Chrome follows a six‑week cycle where testing of the previous version overlaps with development of the next, a pattern similar to the team’s adjusted workflow.

Conclusion

There is no universal silver bullet for software engineering; processes must evolve with project needs. By introducing stable release branches, ensuring sufficient testing windows, and applying a holiday moratorium, the team achieved higher stability while maintaining a weekly release cadence.