Article · 21 September 2026 · 4 min read

Promote the image, not the branch

There is a quiet lie in many release processes: QA validates one artifact, and production rebuilds another from the same commit, hoping the toolchain behaves identically twice. Most days it does. The day it does not, you ship something nobody tested.

Rebuild and hope is not a strategy

A rebuild is a second run of everything that can drift: base images, dependency resolution, build args, the builder itself. The commit is the same, the bytes are not guaranteed to be. If your process rebuilds for production, your real test coverage of what ships is exactly zero.

The shape that removes the lie

We run two long-lived branches. Develop takes the merge requests, deploys to QA, and runs the health checks. Main is the production line, and no feature ever merges into it directly. A release is tag-first: an annotated tag lands on the QA-validated commit, then main moves to that exact commit, so the tag and the branch agree about what shipped.

The artifact follows the same rule. The release job pulls the QA image from the registry, retags it with the production release version, and pushes it back. No production rebuild exists. The bytes that soaked in QA are byte-for-byte the ones production runs, under a new immutable name.

Hotfixes without stranded commits

Urgent fixes branch from main, deploy to QA for validation like anything else, and merge back into develop when they land. That last step is the one most teams skip, and it is how production grows commits that exist nowhere else, waiting to be silently undone by the next release.

What changes day to day

Approvers approve a specific artifact, not a promise. Operators can answer "what is running in prod" with a tag that means one thing. And the whole release conversation shrinks, because "did we test what we shipped" stops being a question.