GitHub Actions vs Azure Pipelines: Complete Comparison (CI/CD Selection, Self-hosted Runners, OIDC)

Both are CI/CD services from Microsoft. GitHub Actions is the CI/CD feature of GitHub (acquired by Microsoft in 2018), tightly integrated with the repository and dominant in OSS and individual development. Azure Pipelines is the CI/CD feature of Azure DevOps Services, with a long history in enterprise Azure environments. The two functionally compete, but Microsoft's strategy positions GitHub Actions for new projects and OSS, and Azure Pipelines for existing Azure DevOps environments. Recently, investment in GitHub Actions has accelerated, and Azure Pipelines features (Environments, Approval Gates) are being progressively ported. For new development projects, GitHub Actions is increasingly the standard choice.

GitHub Actions strengths: 1) the GitHub Marketplace offers 25,000+ official and third-party Actions (a dominant ecosystem); 2) natural Pull Request-based integration; 3) effectively free for individual development (unlimited for public repos, 2,000 minutes/month for private); 4) Workflow as Code (.github/workflows/*.yml) is easy to view in the GitHub UI. Azure Pipelines strengths: 1) mature enterprise-grade Environments and Approval Gates; 2) advanced Self-hosted Agent Pool management; 3) Azure Artifacts integration (private registries for nuget/npm/maven/python); 4) centralized Service Connection management. The two are roughly equivalent on the basics (YAML pipelines, multi-stage, matrix build, container jobs). The practical decision axis: choose GitHub Actions when ecosystem matters most, and Azure Pipelines when enterprise management features matter most.

GitHub Actions Self-hosted Runner: install the Runner agent on your own server. More flexible than Microsoft-hosted and able to access intranet resources (on-prem DBs, internal file servers). You can also build auto-scaling runners with GitHub Actions Runner Scale Sets (AKS / VMSS based), integrated with Azure VMSS. Azure Pipelines Self-hosted Agent: registered as an Azure DevOps Agent Pool, pooling multiple Agents, with Capability-based job routing. For new GitHub Actions projects, Microsoft-hosted Runners are usually sufficient. Self-hosted is justified only for special requirements like 1) sensitive data handling, 2) GPU needs, or 3) integration with existing internal infrastructure. In production, be aware of the added burden of OS patching and scaling management on Self-hosted.

Personal Access Token (PAT) / Service Principal Secret: the traditional approach, storing Tokens / Secrets in CI/CD environment variables. Risks include secret leakage, rotation overhead, and token expiry management. OIDC (OpenID Connect) / Workload Identity Federation: standard in GitHub Actions and Azure Pipelines since 2022, providing cloud authentication without secrets. The flow: GitHub Actions / Azure Pipelines issues an OIDC Token → the cloud (Azure, AWS, GCP) verifies the Token → temporary cloud credentials are issued. Azure Pipelines supports OIDC out of the box via the azure/login@v2 Action (Workload Identity Federation). For new projects, OIDC / WIF is the only modern best practice, and secret-based authentication is being phased out.

Matrix Build runs multiple combinations (OS × runtime version × configuration) in parallel. Both platforms let you define this simply in YAML. GitHub Actions example: combine os: [ubuntu-latest, windows-latest, macos-latest] and node: [18, 20, 22] in strategy.matrix to run 9 parallel jobs. Azure Pipelines example: define multiple configurations in strategy.matrix (configuration: { 'Debug-x86': { cfg: 'Debug', plt: 'x86' }, ... }). Common use cases: 1) cross-platform OSS testing (Node.js library on 3 OSes × 3 versions = 9 environments in parallel), 2) multi-arch container image builds (amd64, arm64), 3) Visual Studio C++ multi-config builds. Matrix Build dramatically cuts CI time (sequential 1 hour to parallel 5 minutes) and is a critical feature for developer productivity.

GitHub Actions' reuse mechanisms. Composite Action: bundles multiple Steps into a single Action, defined in action.yml, publishable to the Marketplace. Reusable Workflow: invokes an entire Workflow from another repository, defined with the workflow_call trigger, used as an organization-wide template. Standard patterns: 1) bundle the organization's common Build → Test → Scan → Deploy steps as a Composite Action; 2) standardize cross-repository pipelines as Reusable Workflows (e.g., centrally stored in an org/.github repository); 3) publish to the Marketplace to contribute to the OSS community. The Azure Pipelines equivalent is Pipeline Templates (Stage / Job / Step Templates), which provide similar reusability. In enterprises sharing the same CI/CD logic across dozens or hundreds of repositories, the Composite Action + Reusable Workflow combination dramatically reduces operational burden.

GitHub Actions DevSecOps: 1) GitHub Advanced Security (GHAS) with CodeQL (SAST), Secret Scanning, Dependabot, and Push Protection; 2) Microsoft Defender for DevOps for centralized security management across Azure DevOps / GitHub; 3) Container Image Scanning (Trivy, Microsoft Defender for Containers); 4) IaC scanning (Checkov, tfsec); 5) SBOM generation (Anchore, SPDX). Azure Pipelines DevSecOps: equivalent functionality is delivered through Microsoft Defender for DevOps plus Azure Pipelines Tasks (CodeQL, OWASP Dependency Check, SonarCloud). Both provide strong support for DevSecOps Shift Left (catching vulnerabilities early in the CI/CD pipeline), and in production projects this is essentially required. See the DevSecOps chapter of the AZ-400 complete guide for details.

Both are tested deeply in AZ-400 (DevOps Engineer Expert) Domain 3 (Build and Release Pipelines, 40-45%), with frequent design decisions around YAML syntax, Stage / Job / Step, Approval Gates, Marketplace, and OIDC authentication. Since GitHub Actions is the mainstream choice for new projects, focused study on it is recommended. AZ-104 (Administrator) covers the basics, AZ-204 (Developer Associate, retiring 2026-07) covers CI/CD from a developer's perspective, and AZ-305 (Solutions Architect Expert) covers the architectural view. The Azure DevOps engineer career roadmap also positions GitHub Actions and Azure Pipelines as core technologies.