GitHub Actions: Dependencies and Concurrency

"DevOps is not about doing things fast; it is about doing them in the right order."

Imagine you have a pipeline that deploys your website to Production.

1. Developer A pushes code. The deployment starts.
2. $10$ seconds later, Developer B pushes code. A SECOND deployment starts.
3. The Disaster: They both try to update the database at the same millisecond. Your website crashes.

Concurrency Groups solve this by telling GitHub: "Only one deployment at a time!" Workflow Dependencies solve the order: "Don't deploy until the tests are Green!" This 1,500+ word guide is your architectural manual for the Logic of Order.

1. Concurrency Groups: The "One-Way" Gate

A concurrency group ensures that only one "Instance" of a job runs for a specific group name.

Why this is Professional: When Developer B pushes their code, GitHub sees that Developer A is already deploying. It "Kills" Developer A's job and starts the new one. This ensures that the Latest Code is always the one that wins.

2. Job Dependencies: The needs Keyword

Inside a single YAML file, jobs run in Parallel (all at once) by default.

• You don't want to "Deploy" while the "Tests" are still running.
• You use needs.

3. Workflow Dependencies: workflow_run

Sometimes you have two Separate Files.

• File A: Builds your mobile app.
• File B: Sends a Slack notification. You can tell File B to wait for File A using the workflow_run trigger.

4. The "Failure Propagation" Rule

What if you have 5 jobs that all "Need" each other? Job 1 -> Job 2 -> Job 3.

• If Job 1 fails, Job 2 and 3 are automatically cancelled.
• This stops you from wasting money and time on a "Gauranteed Failure."

5. Performance: Grouping by Branch

You can make your concurrency groups smarter by including the branch name.

The Benefit: This allows multiple developers to work on DIFFERENT features at the same time without "Killing" each other's test runs. Only deployments to the SAME branch will clash.

Summary: The Order Checklist

1. Concurrency Groups: Mandatory for any job that touches a Database or Cloud server.
2. Needs Keyword: Use it to create a "Waterfall" logic (Test -> Build -> Ship).
3. Workflow_Run: Use it to connect separate YAML files into one "Master Pipeline."
4. Cancel-in-progress: Always set to true for branch deployments to save GitHub Action minutes.
5. Failure Awareness: Ensure your later jobs don't start if the early jobs are Red.

Dependencies and Concurrency are the "Orchestration" of your engineering. By mastering the gates of the needs keyword and the safety of concurrency groups, you gain the ability to manage massive, high-velocity teams where code is shipped thousands of times a day with zero clashes. You graduate from "Running jobs" to "Architecting the Lifecycle."

Part of the GitHub Mastery Course — engineering the queue.