Ship — Overview
Ship is the release runbook for a reflutter app. Invoked as
/reflutter:ship, it drives a staged rollout from a ready main to verified
artifacts in internal testing: building, checking, and interpreting along the
way, and stopping at every point where the decision is yours.
It is user-invoked only. A release is deliberate and irreversible, so nothing starts one on your behalf.
When to reach for it
Two things must be true:
- There is something on
mainworth shipping — committed, pushed, with changelog entries to show for it. - The app is on the train: it has a
fastlane/Pluginfilewired tofastlane-plugin-flutter_deployand areflutter.jsonwith areleaseblock. Every per-app fact (lane names, flavors, app ids) comes from that file — the runbook itself is app-agnostic.
Not on the train yet? One skill onboards an app.
/reflutter:instrumenting-release-lanes scaffolds the fastlane setup, writes
the release block, and proves the wiring with a dry run of every lane,
without ever running anything live. See The skills.
What it will and won’t do
It will:
- Run analysis and tests.
- Prove your env values are current.
- Bump the version and cut the release candidate.
- Build both artifacts and verify their freshness.
- Interpret any failure into an exact next action.
It will never:
- Upload on its own initiative. Every upload happens behind your explicit, per-upload approval.
- Accept an Apple agreement or touch your certificates. Those are legal acts, and they are yours.
- Advance a gate. On-device verification, copy approval, and console actions are passed by your words, never by inference.
The reasoning behind those three “never” lines has its own page: Release Interlocks.
The shape of a release
| Step | Who acts | What happens |
|---|---|---|
prepare |
Lane | Bump, cut rc/X.Y.Z, build. Dry run, then your go. |
store-notes |
You | Drafted for you, approved by you. |
upload |
Lane | To internal testing, behind per-upload approval. |
verify |
You | On your device. Asked, never assumed. |
promote |
Lane | Same source, same build number, to production. |
finalize |
Lane | Tag X.Y.Z, drop the RC scaffolding, after integrity checks. |
Two pages go deeper:
- Running a release is the full walkthrough, gate by gate.
- The release model is the doctrine underneath: why the candidate is frozen source, why the build number never changes, and why finalize is the dangerous step. Read it once before your first train; everything else can be learned by doing.