Mapping Azure DevOps Multi-Stage Pipelines to GitHub Actions - Part 1

 Migrating from Azure DevOps to GitHub Actions is mostly about rethinking stages → jobs, and stage dependencies → job dependencies (needs) while keeping environments and deployment isolation intact. This is a bit challanging task as GitHub actions does not support independant varaible groups and environments as in Azure DevOps. In this post let's look at  how a classic multi-stage deployment flow can be represented cleanly in GitHub Actions.

The Source Azure DevOps pipline can be a single env deployment such as below.

Or it can be even multi stage pipline with multiple target environments.

Before we try to achive above shown multi stage pipline behaviours in GitHub actions we have to understand below key fundemantal diffrances in Azure pipelines vs GitHub actions.

Variable Groups vs Environment-Scoped Approvals (Azure DevOps vs GitHub Actions)

Concept	Azure DevOps Pipelines	GitHub Actions
Reusable variables (global/config)	✔ Variable Groups (Variable Group in Library)	✔ Environments, Repository Variables, Organization Variables
Scope of variables	Linked explicitly to pipelines or stages via variable group reference	Scoped via Environment, Repository, or Org level
Secret storage	✔ Variable Groups (can link to Key Vault)	✔ GitHub Secrets (Repo / Org / Environment secrets)
Environment-based variables	✔ Supported via variable groups per environment	✔ Native via environment: blocks
Runtime variable injection	✔ Yes (variable groups + templates)	⚠ Limited (mostly predefined at workflow start)
Dynamic variable selection	✔ Strong (based on stages/templates/conditions)	⚠ Limited (based on job conditions, not dynamic injection)

---

Approval & Environment Protection Model

Concept	Azure DevOps Pipelines	GitHub Actions
Environment approvals	✔ Built-in Environment approvals (pre-deployment gates)	✔ Environment protection rules (required reviewers)
Where approvals are configured	Inside Azure DevOps Environments or release pipelines	Inside GitHub Environments settings
Approval granularity	Stage-level approvals	Job-level approvals (via environment:)
Manual intervention gates	✔ “Manual validation” tasks	⚠ No direct equivalent (simulated using environments or workflows)
Checks before deployment	✔ Gates, approvals, checks, policies	✔ Required reviewers, status checks, branch protection
Policy flexibility	Very granular (queries, gates, time windows, etc.)	Simpler model (reviewers + required checks)

Key Difference Summary

• Azure DevOps
  • Centralized variable management via Variable Groups
  • Highly flexible pre-stage approval gates
  • Strong coupling between stages + environments + variables
• GitHub Actions
  • Environment-based model is more job-centric
  • Approvals are tied directly to jobs using environment:
  • Variable and secret scoping is simpler but less dynamic

Key Limitation Summary (Azure DevOps vs GitHub Actions) in YAML

Capability	Azure DevOps	GitHub Actions
Stage templates	✔ Yes	❌ No
Job templates	✔ Yes	⚠ Partial (reusable workflows only)
Step templates	✔ Yes	✔ Composite actions
Dynamic pipeline generation	✔ Yes (via templates)	❌ No
Dynamic DAG construction	✔ Yes	❌ No
Multi-job templated stages	✔ Yes	❌ No
Heterogeneous job generation (different logic per job via template)	✔ Yes	❌ No
Matrix-based parallelism (same job logic)	✔ Yes	✔ Yes (but limited to identical job structure)
Conditional injection of pipeline structure	✔ Yes	⚠ Limited (job-level only via if)

What is a DAG?

DAG (Directed Acyclic Graph) is the execution model used by both Azure DevOps and GitHub Actions to determine how jobs and steps run.

• Directed → Work flows in one direction (A → B → C)
• Acyclic → No loops are allowed (you cannot return to a previous step/job)
• Graph → A structure of nodes (jobs) connected by edges (dependencies)

In CI/CD terms:

• Each job or stage = a node
• Each dependency (dependsOn / needs) = an edge
• The system executes jobs in an order that respects these dependencies

Key Difference in DAG Handling

• Azure DevOps: DAG can be dynamically generated using templates and parameters
• GitHub Actions: DAG must be fully defined before execution starts (static DAG)

One-line summary

Azure DevOps allows dynamic DAG construction through templated stages and jobs, while GitHub Actions requires a fully defined static DAG where reuse is limited to execution units (jobs and steps).

With understanding of these limitations we discussed above, in next blog, let's look at how we can come up with a workflow model to achieve deployments similar to azure pipelines.