Ken Muse

Comparing Azure DevOps and GitHub

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 DevOpsGitHubNotes
AgentRunnerBoth 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.
ApprovalEnvironment approverGitHub 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.
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 workflowGitHub does not have a standalone, graphical build process. It relies on YAML-based pipelines that manage an end-to-end flow.
Container jobContainer 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
DemandsRuns-onSpecifies the environment used for executing the job steps.
EnvironmentEnvironmentGitHub allows you to create environments to restrict access to secrets, log deployments, and support OIDC. See also Gates.
Deployment protection rules
Environments can apply some restrictions similar to gates. GitHub allows for custom deployment protection rules ( sample).
Hosted agentGitHub-hosted runnerLarger hosted runners add configurable VM sizes, Azure VNET injection, and fixed IP ranges.
Job conditionJob condition-
LibrarySecretBase64 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 pipelinesActions workflows-
PackagesPackagesGitHub does not yet support Python packages, upstream source proxying (except for npm), or feed views
PipelineActions workflowGitHub Actions and YAML pipelines are closely related. GitHub does not support a graphical form-based editor.
Private AgentSelf-hosted runner-
Release ManagementActions workflow
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.
Scale-set agentActions 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 containerService 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 conditionStep 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.
TaskActionTasks were created and distributed using a VSIX file; Actions are distribute using open-source GitHub repositories.
Task groupComposite actionSee Template.
TemplateReusable 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
TriggerTrigger/EventTriggers start an Actions workflow based on a specific event.
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": .value.value}] | from_entries' YOURFILE.yml -o p >> $GITHUB_ENV
yq e '.variables[] | to_entries | [{"key":.[0].value, "value": .[1].value}] | from_entries' YOURFILE.yml -o p >> $GITHUB_ENV.
Work ItemsIssueSee Boards.
Workload identity federationOIDCThis 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.