If you’re moving from Azure DevOps pipelines to GitHub Actions, the terminology differences can sometimes get a little overwhelming. Even though they have the same roots, there are enough differences that it can sometimes be challenging to understand the equivalent features or patterns. Microsoft provides some details about the feature differences, but it’s not always clear how to map the concepts.
I’ve tried to capture some details here to make that transition a bit easier. In some cases, the features are similar enough that the mapping is equivalent. In other cases, there is no direct equivalent, but there are workarounds or alternative design patterns that can be used.
| Azure DevOps | GitHub | Notes |
|---|---|---|
| Agent | Runner | Both are .NET based with an integrated NodeJS environment. GitHub offers self-hosted, GitHub-hosted, and GitHub-hosted larger runners (with VNET injection support in beta). |
| Analytics | - | See Dashboards. GitHub does not provide an OData feed, data warehouse, or dashboard for analytics. A custom GitHub App and webhook can be used to gather and stage data for reporting purposes. |
| Approval | Environment approver | GitHub only supports approval before a job starts. For post-approval, use an additional job. |
| Artifact (build) | Artifacts (workflow run) | Artifacts in GitHub have a default retention of 90 days. For versioned resources, discoverability, or to store long-lived artifacts, consider Packages or Releases. |
| Boards | Issues Projects | Issues are optimized for lean/agile processes and do not support customizable views and complex form layouts. Projects provides a way to visualize issues as a board, backlog, or roadmap. |
| Build (classic Pipelines) | Actions workflow | GitHub does not have a standalone, graphical build process. It relies on YAML-based pipelines that manage an end-to-end flow. |
| Container job | Container job | - |
| Dashboards | - | No GitHub equivalent. GitHub
Pages can be used to create web sites which can host widgets and content; it can be populated with content using standard Git operations and deployed using Actions. GitHub does support a
workflow status badge that can be added to the repository README.md. |
| Demands | Runs-on | Specifies the environment used for executing the job steps. |
| Environment | Environment | GitHub allows you to create environments to restrict access to secrets, log deployments, and support OIDC. See also Gates. |
| Gates | Environment Deployment protection rules | Environments can apply some restrictions similar to gates. GitHub allows for custom deployment protection rules ( sample). |
| Hosted agent | GitHub-hosted runner | Larger hosted runners add configurable VM sizes, Azure VNET injection, and fixed IP ranges. |
| Job | Job | - |
| Job condition | Job condition | - |
| Library | Secret | Base64 encoded file content (up to 48 KB) can be stored in a secret. For larger files, they should be stored in a secured location and retrieved using OIDC or a secret. |
| Multi-stage pipelines | Actions workflows | - |
| Packages | Packages | GitHub does not yet support Python packages, upstream source proxying (except for npm), or feed views |
| Pipeline | Actions workflow | GitHub Actions and YAML pipelines are closely related. GitHub does not support a graphical form-based editor. |
| Private Agent | Self-hosted runner | - |
| Release Management | Actions workflow Deployment Release Environment | Similar to Azure DevOps’ pivot to multi-stage YAML pipelines, GitHub does not have a standalone release management tool that can be triggered by other releases or builds. Instead, workflows with appropriate triggers can create deployments. Creating a release can also offer similar functionality. |
| Run | Run | - |
| Scale-set agent | Actions Runner Controller Larger hosted runner | ARC is self-hosted Kubernetes-based environment with container-based runner scaling. Larger hosted runners provide configurable VM scaling in Azure (SKU not configurable). |
| Service container | Service container. | - |
| Service endpoint | - | No GitHub equivalent. Replace with OIDC (where possible) and organization secrets (shared) or repository/environment secrets (private). |
| Stage | - | No GitHub equivalent. GitHub jobs and environments provide similar functionality and assume a stage has only one job. |
| Step condition | Step condition | - |
| Step loop | - | Step-level
each loops are not supported on GitHub. Loops can be achieved at the job level using a matrix strategy or within a job by using scripts. |
| Step | Step | - |
| Task | Action | Tasks were created and distributed using a VSIX file; Actions are distribute using open-source GitHub repositories. |
| Task group | Composite action | See Template. |
| Template | Reusable workflow Composite action | Reusable workflows support multiple jobs, while Composite Actions support multiple steps. Composite actions allow you to compose multiple steps together as a single task within the current job. Unlike Azure DevOps, the output from each step will be grouped under that single task. Reusable workflows run one or more jobs and give visibility to the individual steps. GitHub “templates” refers to starter workflows and template repositories |
| Trigger | Trigger/Event | Triggers start an Actions workflow based on a specific event. |
| Variable | Variable Secret | GitHub variables and secrets can be configured at the environment, repository, and organization levels. GitHub visually and logically separates variables and secrets, rather than allowing a variable to configured as a secret. This adds clarity to where a secret is used. |
| Variable group | - | No GitHub equivalent. If this is needed, there are some workarounds. That said, in many cases, this can indicate too much project-level information is leaking into the deployment process (or that the configuration is monolithic); a migration can offer an opportunity to modernize. |
| Variable Template | - | No GitHub equivalent, but similar handling to Variable Groups. You can promote variables from YML files into environment variables (or step outputs) using
yq. For example:yq e 'to_entries | .[] | [{"key":.value.name, "value": .value.value}] | from_entries' YOURFILE.yml -o p >> $GITHUB_ENVor yq e '.variables[] | to_entries | [{"key":.[0].value, "value": .[1].value}] | from_entries' YOURFILE.yml -o p >> $GITHUB_ENV. |
| Work Items | Issue | See Boards. |
| Workload identity federation | OIDC | This will be the recommended replacement for Azure service connections in Azure DevOps once it GAs ( Announcement). GitHub recommends OIDC for standards-based, passwordless, secure connections to resources. |