A food-delivery company in Zomato's mould releases a backend container plus three signed mobile bundles (iOS, Android, and a lightweight Android build) every two weeks. The team wants one promotion decision covering all four artefacts, auditable later. Which approach should they adopt?

The deciding property

The promotion must name immutable things, and it must name all of them in one place. A release is four artefacts that were tested together; if the promotion decision refers to anything that can resolve differently later, the claim "production runs what was tested" is false and nobody will notice until it matters.

Why the release manifest

A manifest is a small signed document listing every artefact by content digest — the container image, each mobile bundle, and the configuration and migration set that go with them — plus the commit and the build that produced each. Promotion then means signing that document for the next environment, and deployment means resolving it.

What that buys:

• One atomic decision. Four artefacts are promoted or none are. There is no state where the backend is promoted and the Android bundle is from yesterday.
• An audit answer that does not depend on memory. "What was in the 12 March release?" is a file, signed, in version control.
• Digests, not names. A digest is the content; a tag is a pointer that can be moved. Two deployments referencing service:1.8.2 can be different images, and that is the single most common cause of "it works in one region and not the other".
• Room for the things that are not artefacts. Chart values, feature-flag defaults and the migration set are part of what makes a release, and a manifest can pin them. A promotion that pins only the image is a partial promotion, because the configuration is resolved fresh at deploy time.

Why the other options fail

Promote by git tag. A tag is a name, and names are mutable and resolved late. Each environment resolving the tag independently can pick up a different build, a different base image pulled by tag, or a different dependency version if the build is not hermetic. It also fails the audit question: a tag tells you what source was intended, not what binary ran.

Rebuild per environment. This is the version that feels rigorous and is the least safe: four builds means four chances for a different base image, a different transitive dependency, or a different toolchain version. The artefact tested is then provably not the artefact shipped, and the whole point of promotion is lost. Mobile makes it worse — a rebuilt bundle has a different signature and a different binary, which in some stores means a separate review.

Promote the container and rebuild mobile separately. It splits the release into two decisions with no linkage, which is the state the team is trying to leave. Mobile and backend have a contract between them; promoting them independently means nothing records which backend a given bundle was verified against.

When not to build a manifest, and what would flip it

For a single artefact going to a single environment, a manifest is ceremony: promote the digest and stop. The machinery earns its place at two or more artefacts that must move together, or at the first audit question nobody can answer from memory.

What else the manifest needs to be useful

A record of where each manifest is currently deployed. A signed list of digests answers "what is in this release" and not "what is running in production right now", and during an incident the second question is the one being asked.