Release and distribute
Release begins after packaging. At this stage you already have an artifact manifest. The release workflow prepares metadata, checks provider requirements, uploads or submits the artifact, and records what happened.
The release loop
Step | Command shape | What it proves |
|---|---|---|
Validate release content | fission release-content validate ... | Notes, screenshots, privacy files, review material, and store metadata exist and match provider requirements. |
Check provider readiness | fission readiness distribute ... | Credentials, provider tools, package identity, tracks, and artifact shape are valid before upload. |
Distribute | fission distribute ... or fission publish ... | The manifest-backed artifact is uploaded or submitted to the selected provider. |
Keep the receipt | target/fission/distribution/... | The team can later prove which asset, hash, provider id, URL, or rollout state was produced. |
Release commands should fail with diagnosable errors. Missing credentials, expired auth, invalid tracks, absent screenshots, and provider rejections should be safe to fix and retry.
Choose a local or CI release path
Use the same release model in every shell, but choose the interface that matches
the job.
Path | Command | Best fit |
|---|---|---|
Guided local flow | fission publish --provider play-store | A developer is setting up a provider, signing, release notes, screenshots, or tracks for the first time. |
Windowed local flow | fission publish --provider play-store --app | A developer wants the visual release wizard and native file dialogs. |
Direct CI flow | fission readiness ... --json, fission package ... --json, fission publish ... --artifact ... --yes --json | Automation should build one artifact, publish that exact manifest, and fail without prompting. |
Provider lifecycle operation | `fission distribute status | promote |
The guided shells can help discover missing setup, but they are not a different
release system. They render the same plan, requirements, jobs, and receipts as
direct commands.
Pick the provider page
Destination | Start here | Common artifacts |
|---|---|---|
GitHub release assets | installers, binaries, archives, APK/AAB/IPA, static site zip | |
Static website hosting | static site manifest | |
Mobile and desktop stores | AAB, IPA, MSIX, store metadata | |
Container registry | static or server Docker image | |
Buckets and object stores | arbitrary package assets and static files | |
Notes, screenshots, review files | provider metadata and human-facing release material |
Use Release lifecycle details when you need the full command model and provider lifecycle rather than one provider path.
Keep fission.toml readable
fission.toml is the root manifest. Put stable facts there: app id, version, target declarations, provider references, release tracks, and paths to release-content files.
Do not put full release notes, long localized store descriptions, screenshot inventories, or review attachments directly into fission.toml. Put those in referenced files so people can review them and reuse them across CI.
Receipts matter
A release receipt records provider ids, URLs, deployment ids, uploaded bytes, artifact hashes, release status, and follow-up steps. Keep receipts in CI artifacts or release records. They answer practical questions later: what was uploaded, where did it go, which hash did we publish, and what did the provider return?
Next steps
If you do not have an artifact manifest yet, go back to Build and package. If you are preparing a store or public release, start with Release content before upload.
Release flows
Use Local publishing when a developer is proving the flow interactively on their machine. Use CI publishing when all choices and secrets are supplied non-interactively. In both cases, follow the App release checklist before upload.
Previous
Server site packages