How the two CI/CD platforms compare on hosting, YAML, integrations and licensing, and when to combine them.
From Ultra Transcenders AZ-400 by Tony Rough (coming November 2026)
Both services define automation as YAML stored with the code and run jobs made of sequential steps on hosted or self-hosted machines; the differences are in structure, reuse and where the code lives.
GitHub Actions is the CI/CD service built into GitHub. A workflow lives in .github/workflows/*.yml, contains jobs, and each job contains steps that run shell commands (run) or reusable actions (uses: owner/action@version). Azure Pipelines is the CI/CD service of Azure DevOps. A pipeline (commonly azure-pipelines.yml) can contain stages, jobs and steps, and steps are scripts or tasks (task: Name@version). Azure Pipelines can build code in Azure Repos Git, GitHub, GitHub Enterprise and Bitbucket Cloud, so the choice of CI/CD service does not force a choice of repository host.
| Aspect | Azure Pipelines | GitHub Actions |
|---|---|---|
| Definition file | Any YAML file in the repo, typically azure-pipelines.yml |
.github/workflows/*.yml |
| Hierarchy | Stages > jobs > steps (stage and job can be implied) | Jobs > steps; structure can’t be omitted |
| Stages | Native stages in one file |
No stages; split into separate workflows or use reusable workflows |
| Reusable step unit | Task, for example UsePythonVersion@0 |
Action, for example actions/setup-python@v5 |
| Script keywords | script, bash, powershell, pwsh |
run with optional shell |
| Default shell on Windows | CMD | PowerShell |
| Conditions | condition: eq(variables.str, 'ABC') (function syntax) |
if: ${{ env.str == 'ABC' }} (infix operators) |
| Job dependencies | dependsOn |
needs |
| Selecting self-hosted machines | Agent pool plus demands matched to capabilities | Runner labels and runner groups in runs-on |
| Deployment controls | Environments with approvals and checks defined outside YAML | Environments with protection rules |
| Credentials to Azure | Service connections | Secrets or OpenID Connect |
| Graphical editor | Classic editor still exists for older pipelines | None; YAML only |
When the two are combined, the usual patterns are Azure Pipelines building a GitHub repository (covered later in this chapter) or a GitHub Actions workflow starting an Azure Pipelines run with the Azure/pipelines action, which takes the project URL, pipeline name and an Azure DevOps personal access token (PAT) as inputs. Migration tooling also exists in the other direction: GitHub Actions Importer (gh actions-importer) audits and converts Azure Pipelines definitions into workflows.
Classic (designer) pipelines remain supported for existing work, but new organisations have Disable creation of classic build pipelines and Disable creation of classic release pipelines turned on by default, and Microsoft recommends YAML pipelines because they’re versioned, reviewable through pull requests and protected by resource authorisation.
Common trap: Assuming a GitHub-hosted repository must use GitHub Actions - Azure Pipelines builds GitHub, GitHub Enterprise and Bitbucket Cloud repositories as well as Azure Repos, so the CI/CD service is chosen on features (stages, checks, existing tasks) rather than on where the code lives.
This note is one section of Ultra Transcenders AZ-400: Designing and Implementing Microsoft DevOps Solutions, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.
Due on Amazon in November 2026, in Kindle and paperback editions.
About the book · AZ-400 terms in the glossary · All AZ-400 study notes
How trunk-based development, GitHub Flow, feature branches, release branches and forks differ, and which fits a team's release cadence.
Which agent or runner option fits private network access, custom software, scale and maintenance requirements.
How each release pattern limits risk, what it costs and how traffic or users move to the new version.
How @Local, @Prerelease and @Release views work, how promotion moves packages through them and who consumes each view.
When a pipeline should use a service principal, a system-assigned or a user-assigned managed identity, and the trade-offs of each.
The four DORA metrics, where to get the data in Azure DevOps and GitHub, and which metrics suit planning, development, testing, security, delivery and operations.
How Git LFS pointer files and storage work in Azure Repos and GitHub, the limits on each platform and what pipelines need to fetch LFS content.