Start with the resource, not the repository
Two successful pipelines can still compete for one environment. Separate repositories do not establish independence when both update the same service, infrastructure state or shared dependency. Begin with a map of what each deployment can change. Keep builds and tests parallel where they do not mutate that shared target.
Choose a useful concurrency boundary
List the resources that cannot safely receive overlapping changes and identify their owners. A single global queue may delay independent applications, while a lock per branch may fail to protect a shared production environment. Treat the boundary as an architecture decision. Record the resource name, participating workflows and the operation that acquires and releases access.
Separate ordering from safety
Serial execution and release order are different questions. A queue can prevent overlap without proving that the next candidate is still intended for deployment. Decide whether waiting changes must run in their original order or whether a newer approved candidate may supersede one. Review migrations and other dependency-sensitive changes before adopting a newest-first policy.
Define when cancellation is safe
A candidate that has not started changing the target may be easier to retire than an operation already applying infrastructure or data changes. Identify side effects and explicit interruption boundaries. Do not use automatic cancellation as a substitute for understanding partial completion. Name the person who decides what happens after an interrupted change.
Rehearse two competing releases
Use a suitable non-production environment. Start a representative release, then submit another candidate for the same resource. Observe whether it waits and whether independent work continues. Exercise a failed or interrupted first run, verify resource ownership and confirm that a stale candidate cannot proceed on outdated approval. Preserve non-sensitive evidence of the behavior.