Release safety

Build predictable release processes that prevent avoidable failures.

Protect validation with controlled concurrency

Validation only works if the release under test cannot change while checks are still in progress. If a newer release can immediately replace the candidate being tested, the validation stage stops answering the question that matters: whether this specific release is ready to continue.

Consider a test environment. If release #334 enters validation and release #335 deploys into the same environment, passing validation no longer answers the question: is #334 ready to continue?

A stage lock solves this by limiting stage concurrency. While a release is active, later releases wait instead of replacing the environment.

Stage locks can be implemented using group concurrency. A group can allow multiple active releases or restrict execution to a single active release at a time.

Unsafe: validation continues after the release candidate changes.

#334validation running

#334validation invalidated

#335deployed (candidate replaced)

Safe: later releases wait until validation completes.

#334validation running

#334validation completed

#335queued (group concurrency = 1)

#335deployed

Operators can see which release currently owns the stage, which releases are queued behind it, and why execution has paused.

Batch early. Preserve order later.

Early release stages often benefit from batching. When changes are still close to the development loop, newer releases can supersede older ones so long-running validation, bake time, and review stages do not become the limiting factor for release velocity.

Later stages have a different safety profile. If releases are batched after validation, the team may be deploying a combination that never moved through earlier stages together. That can hide ordering assumptions, compatibility issues, or recovery boundaries that only appear when changes are deployed separately.

A predictable process can use both modes deliberately: batch where speed reduces noise, then preserve order where tested sequence, traceability, and recovery matter more than raw throughput.

Unsafe: releases were tested separately, then batched later.

test

production

#334queued

#334deployed

#335queued

#335deployed

#334queued

#334replaced

#335queued

#335deployed (late batching)

Safe: batch early, then preserve the tested sequence

test

production

#334queued

#334replaced

#335queued

#335deployed (latest)

#335queued

#335deployed (preserve sequence)

#336queued

#336deployed (latest)

#336queued

#336deployed (preserve sequence)