One release, end to end

Every week, Spotify ships a new version of its mobile app to more than 675 million users. Behind that cadence is a Release team with two jobs: coordinating each release of the main app and building the tooling to support that process. The team's daily work is led by a full-time Release Manager.

Two goals drive the team's core responsibilities:

  • Keep the time from a developer merging code to users getting it as short as possible
  • Make sure quality meets Spotify's standards

These goals sometimes pull in opposite directions. Release management is largely about managing that tension through tooling and informed decisions. Typical balancing acts include:

  • Prioritizing bugs: A crash during signup or playback is treated differently from one that happens after logout.
  • Finding a fallback: If a bug only hits one A/B test group, backend config can route all users to the working experience while a client fix waits for the next release.
  • Acting fast when it matters: A bug affecting a small but important user group, such as crashes in a particular region, may justify a quick fix.

To show how this works in practice, here is the path of one release, version 8.9.2, from first commit to full availability.

Week 1: Building on the main branch

Each cycle starts on a Friday morning, right after the previous version has been cut from the main branch. Spotify uses trunk-based development, so most code lands on main as soon as it is reviewed and tested. Large infrastructure changes are an exception and are merged early in the cycle, typically on that first Friday. That gives internal teams and external alpha users more time to shake out issues.

For 8.9.2, the major planned change was enabling the Audiobooks feature in certain markets. The feature had been running behind a feature flag for several releases while internal testers looked for bugs. Because marketing events were already scheduled around the launch, the Release Manager ensured Audiobooks was the only major feature rolling out in that cycle; another large feature originally scheduled for the same week was moved to the next release.

Teams could still merge throughout the week, but were strongly encouraged to use feature flags, or at least avoid high-risk changes during the release week.

The daily rhythm during Week 1 is consistent:

  • Nightly builds from main go out to internal users and alpha testers each morning.
  • Developers merge code after testing and review.
  • Alpha users file bug reports. When the reporter does not know which team owns the affected feature, the Release Manager assigns the ticket.
  • Crash rates and other metrics are tracked per build. Automatic tickets trigger when metrics exceed a severity threshold; manual tickets are filed by the Release Manager or other staff.

All of that status is aggregated in the Release Manager Dashboard, which shows blocking bugs, the latest passing build in the alpha program, crashes and ANRs per unit of consumption, daily usage, and the health of distribution jobs.

During this cycle, Audiobooks was enabled for most employees. The Release Manager and the Audiobooks team combed through crash reports looking for anything that could threaten the planned launch. Even a minor crash affecting a handful of employees could point to a problem that would scale to a large user base at rollout, so issues were investigated promptly.

Week 2: Branching and hardening

On the second Friday, the release branch for 8.9.2 is cut. From this point on, the version is the "current" release and only critical bug fixes are accepted. Less urgent fixes and new features wait for the next weekly cycle, which discourages risky last-minute changes.

After branching, the Release Manager coordinates the work needed to ship the branch. While alpha builds come from main, public beta builds are pulled from the release branch and are expected to be more stable. On Fridays in Week 2, teams run manual regression testing on features they own and report results. Teams with strong automated test coverage can opt out of manual testing.

Bugs discovered during testing, whether in a team's own feature or another's, generate tickets. Crash reports and user bug reports create more. For 8.9.2, the Audiobooks team was especially attentive during this phase, looking for anything that might derail the launch. The team evaluated each issue on risk, impact, and available workarounds before deciding if it justified blocking the release.

Submission and rollout

Beta users provide extra runtime over the weekend after branching. The goal is to submit to the app stores on Monday, though complex bugs can push that back a few days. Coordination during this period happens on a dedicated Slack channel where the Release Manager, feature teams, and stakeholders share updates and flag concerns.

The Release Manager makes sure bugs are routed to the right teams, manual testing results are collected, and release-blocking bugs—typically three to five per release—are fixed on the branch. Before a store submission, the team checks that:

  • All release branch commits are in the latest build and have passed automated tests.
  • No blocking bug tickets are open.
  • All teams have signed off.
  • Crash rates and key metrics are below thresholds.
  • The release candidate has been used to play a sufficient amount of content.

The Release Manager Dashboard marks each criterion green, yellow, or red for a quick health check.

For 8.9.2, the team also prepared test accounts with Audiobooks enabled and provided detailed testing instructions to the app stores so the new feature would not be a surprise during review.

Once a store approves the build, rollout happens in two waves: first to a small percentage of users, then to 100% the following day. After the initial 1% rollout, a typical dashboard still shows a couple of open ITGC tickets—checks that client reporting to the backend is working. Minor bugs found at this stage are acceptable in the current version but become blockers for future releases; in severe cases, a feature rollout can be paused and resumed with the next version.

The small first wave works because of Spotify's user base size: even 1% is enough to surface critical issues that survived internal, alpha, and beta testing. If something severe appears, the rollout pauses and the responsible team starts building a fix. Ideally the fix lands before the next release branches, allowing an updated build to be submitted. Otherwise, the team may face the hard call of canceling either the current or the upcoming release rather than managing two active release branches.

For 8.9.2, once enough users were on the new version, the Audiobooks team started their own phased rollout, enabling the feature for gradually larger percentages of users in specific markets via a backend feature flag. The feature met quality standards and ramped to 100% over the following days. More than 95% of releases make it to all users using this procedure, and the weekly cadence means a canceled release is only a temporary setback—a new version is already on deck for the next week.

How a Weekly Mobile Release Stays on Track

Spotify’s mobile app ships on a weekly cadence, which means the company has to reconcile two competing pressures: pushing out new features quickly while keeping the experience stable for millions of users. The person accountable for that balance is the Release Manager, who coordinates communication across feature teams and stakeholders for the entire release cycle, backed by the Release Squad.

The release cycle is driven by a carefully designed set of internal tools, with the Release Manager Dashboard as the central decision-making surface. The dashboard gives the Release Manager a consolidated view of release health so they can move quickly — approving builds, flagging risks, and coordinating fixes — without having to chase down status across multiple systems.

Tooling That Scales With Process

The dashboard alone isn't the whole story. Spotify maintains detailed, up-to-date documentation for both the tools and the release processes themselves. That documentation acts as a shared reference for all the teams involved, helping everyone understand their role at each stage of the cycle and reducing the friction that comes with handoffs between teams.

Together, the tooling and the process documentation make it possible to catch and resolve issues early rather than letting them surface after users have already updated the app.

What the Cadence Makes Possible

This setup is what allows Spotify to push regular updates without major disruption. The automated checks and coordinated human review keep known problems from leaking into production releases. It's also the foundation for launching new product areas — like Audiobooks — through the same weekly pipeline with minimal user-facing turbulence.