Control concurrency

Start from the behavior you can observe. Preview runs cancel by branch, while production deploys share an environment concurrency group and do not cancel an active release blindly.

Multiple runs can race to deploy older code after newer code or consume the same mutable environment simultaneously. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

It is tempting to let every push race independently against the same production target. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to define concurrency from the resource being protected and choose cancellation behavior from rollback risk. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Turn a verified build artifact into one controlled deployment with environment history and rollback. Record enough evidence that another developer can repeat the result without relying on your memory.

Trigger three rapid commits and observe which test, preview, and production runs continue. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.