One name, one artifact: immutable releases

It works on staging is the saddest sentence in operations when staging and production run different bytes. Rebuilding per environment feels careful and guarantees the opposite: the tested thing is never the shipped thing. Immutable artifacts fix it with one rule: build once, name it once.

Same bytes, different config

Build once at merge. The pipeline produces exactly one artifact per commit: image, archive or bundle, with a unique name carrying version and commit hash.

Promote, never rebuild. Staging, canary and production run the same bytes. Only environment config changes between stages. A promotion is a pointer move, not a build.

Keep the receipt. The artifact name traces back to the exact commit, pipeline run and checks. Rollback means pointing at the previous name, in seconds.

Worked example: a fictional double build

The context below is fictional. Fictional team ParcelTrack (fictional) builds separately for staging and production. A dependency resolves differently between the two builds; staging passes, production crashes on a changed function signature.

The fix is one pipeline producing one tagged image per commit, promoted unchanged through both environments. Next dependency drift breaks staging visibly instead of production silently.

Checklist: releases you can trust

1. One artifact per commit, uniquely named.
2. Same bytes in every environment.
3. Config injected per environment, never baked per stage.
4. Rollback is a pointer move to the previous name.

Related reading

• Hands on: Immutable Artifact Under One Name.
• The revert companion: Git branching that survives incidents.