How do you run a release train for many apps: cadence, branch cuts, ownership, go/no-go criteria, hotfix lanes and shared SDK versions?
Predict first
A feature is not ready on branch-cut day, and teams ask to delay the release a week. What does a release train do?
// A: delay the whole train
// B: ship without the feature (or with it off behind a flag) and catch the next train
// C: merge it untested
- A
- B
- C
Mental model. A commuter train leaves on time whether or not every passenger is ready; people who miss it take the next one, so the line stays predictable and nobody delays the rest.
A release train ships on a fixed schedule (for example every two weeks) whatever is ready, instead of waiting for features: what is not ready waits for the next train, so each release is small, the process is practised and nothing is held hostage. The mechanics: on a fixed day the release branch is cut from main; a stabilisation window allows only fixes (cherry-picked from main, reviewed and tracked); release candidates build in CI and go to TestFlight; a go/no-go meeting or automated gate checks agreed criteria; the build is submitted, released with a phased rollout and watched, and the branch is closed. A release captain (rotating) owns the calendar, the checklist, communication and the decision to halt. Features reach users through flags (see the flags question), so merging code does not mean exposing it, and a risky feature can slip a train without moving the schedule.
With many apps sharing code, add structure. Decide whether apps ride one train (simple, consistent, but one app’s problem can delay all) or independent trains with a compatibility policy. Version shared SDKs and modules semantically (Q360, Q362), publish them to an internal registry, and keep a compatibility matrix of which app versions use which SDK versions, so an incident can be traced to a module change. Define gates that every app meets: crash-free sessions, hang and launch budgets (Q432), accessibility and test health (Q453, Q477), size limits and a clean security scan, measured automatically. Keep a hotfix lane with a shorter checklist, and a freeze policy for peak periods. Measure the process, not only the product: lead time from merge to users, frequency, the share of releases needing a hotfix and time to restore after a bad release. Publish the calendar, the rules for getting a change in, and a blameless review after every incident. At the staff level your job is to make the right thing the default, so releases are uneventful and nobody dreads them.
Predictability is the point of a train; flags let unfinished work ship dark without holding the release.
Common traps
- Holding the train for one more feature. It turns a regular release into an irregular, risky one; ship dark behind a flag and catch the next train.
- No compatibility record between apps and shared SDKs. When something breaks nobody knows which module change caused it.
They might follow up with
- Who decides to halt a release? The release captain, using agreed thresholds, not a negotiation.
- How do many apps share one train safely? Versioned shared modules, a compatibility matrix and common gates measured automatically.
Related questions
- 25.4.1 How do you design feature flags and remote config for a mobile app: flag kinds, defaults, stable percentage…
- 25.2.3 How do you design a release pipeline: hermetic builds, secrets, caching, artefact promotion and the order of…
- 25.3.1 What is the path from an archive to users: TestFlight internal and external testing, review, release options…
- 15.5.2 How do you evolve a public API without breaking callers: deprecation, renames, versioning and source versus…
- 15.6.2 How do you run a shared mobile platform for many apps and teams: layering, ownership, versioning and…
- 20.1.3 How do you run one shared core with several UI leaves on a single release train?
- 21.3.2 How do you build a performance culture on a team: budgets, regression gates, ownership and release guardrails?
- 22.7.2 How do you design a quality system for a large team: test tiers, ownership, coverage, flake budgets and…
← How do you design feature flags and remote config for a mobile app…