Give the release queue an admission rule

Release queues usually begin as a useful list. A build finishes, someone adds it. A hotfix appears, someone moves it to the front. An older candidate waits for approval while a newer candidate targets the same environment. Soon the queue is not describing work that is ready. It is collecting every release-shaped object the organisation might care about.

That ambiguity is expensive. Operators spend the start of each handoff asking which artifact is real, whether the destination is still correct, and who can answer for the candidate. Urgent work receives attention because its label is loud, while incomplete work consumes the same visual authority as a release that has earned its place.

We think a release queue needs an admission rule. Before a candidate enters the operational queue, it should identify the artifact, destination, current owner, and evidence that makes it ready for the next decision.

Admission separates preparation from execution

A build can exist without being ready to release. It may still need signing, environment selection, product approval, or a focused smoke. Those are real tasks, but placing the candidate in the execution queue too early hides which prerequisite is missing.

We prefer two visible states. Preparation holds candidates that are still earning a release decision. The release queue holds candidates that have a complete next action and enough identity to execute or reject that action safely.

This is not bureaucracy for its own sake. It protects the operator from treating position as proof. First in the queue should mean first ready candidate for a named destination, not first item somebody remembered to drag upward.

Four facts earn a place

Artifact identity comes first. A branch name, build number, or latest tag may help a human navigate, but the queue should attach the immutable package or image identity that will move. If the artifact changes, the candidate must be readmitted with proof that belongs to the replacement.

Destination is equally important. Internal testing, a production rollout, and a store submission are different decisions even when they use the same artifact. The queue should not let a candidate inherit approval merely because its destination was edited after admission.

Current owner tells the room who can make the next release decision or resolve missing evidence. Ownership should have an expiry or handoff boundary. A name copied from yesterday's candidate is not useful if that person no longer holds the release.

Readiness evidence explains why operational attention is justified now. This might include a passed build, signing proof, target-specific checks, and the approval required for that environment. The exact set depends on the product. The queue's job is to show the set, not pretend every release earns admission in the same way.

Urgency does not waive identity

Hotfixes need a faster path, but faster should mean fewer justified gates or shorter decision windows. It should not mean unknown artifact, unclear destination, and nobody accountable for the next step.

An emergency admission can be explicit: artifact identified, production destination named, incident owner attached, normal exploratory smoke waived, narrow health proof required before expansion. The record says what changed and what debt remains. The queue can then prioritise the candidate without pretending it followed the ordinary path.

If a candidate cannot meet even the emergency identity boundary, it belongs in preparation or incident coordination. Calling it a release does not make it executable.

Recheck admission when the queue changes the decision

Waiting can make evidence stale. A newer candidate may supersede the artifact. Configuration may change. An approval window may close. The owner may hand off. The queue should re-evaluate the admission facts when one of those dependencies moves rather than leaving the old candidate visually ready.

Superseded candidates should remain visible as history, but they should leave the executable queue. Paused candidates should say what event can readmit them. Rejected candidates should keep the evidence and decision that ended their path. Removing ambiguity is more useful than keeping every candidate close to the deploy button.

We build Ubriot so release state stays attached to the artifact, environment, and decision it supports. An admission rule makes the queue smaller, but that is a benefit. Every remaining item can answer what will move, where it will move, who owns the next decision, and why it deserves operational attention now.