Why a release train

Shipping is a process, not a button

Getting a new version of a mobile app into users’ hands is a long chain of steps:

• Build for two platforms.
• Sign with the right keys.
• Bump the version and the build number.
• Write store notes, per store, per locale.
• Upload to two different consoles.
• Wait for each store to process the binary.
• Test it from the internal track.
• Promote it, then submit it for review.

Every one of those steps can be done by hand. Several are irreversible:

• An uploaded build number is consumed forever.
• A store submission goes to a human reviewer.
• A signed agreement is a contract.

Teams that ship a lot formalize it

High-output teams don’t run that chain from memory. They run release trains: releases leave on a schedule, carrying whatever is ready, through a fixed sequence of checks and approvals. They staff the discipline with release managers and release engineers, whose job is that nothing irreversible happens by accident and that any release can be picked up where it was left.

The process exists because at high volume, “we’ll be careful” stops working. Every manual step is a chance to burn something.

The gap

A solo developer or a small team faces the same chain and the same irreversible steps, with none of the staffing. The process lives in your head and your terminal history. It works, until:

• The release that gets interrupted on Friday.
• The step that gets skipped once.
• The Monday morning where “where were we?” has no answer.

The reflutter way

reflutter hands you the train already assembled:

• Deterministic lanes do the repeatable work — bump, build, verify, upload — identically every run.
• Skills operate those lanes in the right order, interpret failures, and stop at every point where a decision is yours.
• You take the one role that can’t be automated: the release manager. Every irreversible act waits for your explicit word, and that boundary is built in, not promised. See Release Interlocks.

You get the enterprise discipline without the enterprise staffing.

What’s in this section

Page	What it covers
Overview	When to reach for Ship, what it will and won’t do, and how to get an app onto the train.
The release model	Why the train is shaped the way it is: frozen candidates, carried build numbers, gates, and the one destructive step.
The skills	The skill family, grouped by the question each one answers, with a use case for each.
Running a release	The full walkthrough: every command, every gate, start to finish.

Start with the Overview.