Concurrency groups
Prevent overlapping release work
Lesson 14 of 20 · 12 min · Module 5: Environments and release identity
Two competing deployments can race even when both pipelines are individually valid.
Start this lesson →Free. No installation: you write and run the code in your browser, and it is checked automatically.
By the end, you’ll be able to…
- Identify competing work
- Choose a meaningful group
The idea
A workflow combines an event boundary, job dependencies, and ordered steps. Conditions and prerequisite outcomes determine which jobs can run.
01Identify competing work
Several commits can produce overlapping runs. A release policy should decide which work can proceed together and what happens to superseded work.
02Choose a meaningful group
The group should represent the shared release target. An unrelated per-run identifier would not bring competing deployments into the same boundary.
03Choose cancellation for the operation
Cancelling stale staging work can be useful. Production migrations or irreversible operations may need a different policy rather than automatic cancellation.
Your turn
What the checks look for
- Names the shared staging group
- Cancels superseded work in the declaration
Take this with you
Choose overlap and cancellation behavior from the operation being performed.
Go a little further
Describe a case where queued execution is preferable to cancelling an active deployment.