6.2 GitHub-Azure Pipelines Integration & Hybrid Migration

6.2 GitHub-Azure Pipelines Integration & Hybrid Migration

Many organizations do not choose one product outright. They keep source in GitHub and orchestrate in Azure Pipelines, or run both side by side during a migration. The connection type chosen for that link determines whether the integration survives an employee offboarding.

1. Hybrid CI/CD Architectures

Enterprise organizations frequently operate in a hybrid model where source code lives in GitHub Enterprise while continuous delivery to Azure environments is orchestrated by Azure Pipelines, or vice versa.

Triggering Azure Pipelines from GitHub Repositories

To build and deploy GitHub repositories using Azure Pipelines, engineers configure a GitHub Service Connection in Azure DevOps:

1. GitHub App Connection (Recommended): Installs the Azure Pipelines app on the GitHub organization. Authenticates via OAuth without storing personal access tokens (PATs).
2. Personal Access Token (PAT) / OAuth: Direct integration where Azure DevOps registers webhooks in the GitHub repository.
3. Webhook Mechanics: When an engineer pushes commits or opens pull requests in GitHub, GitHub dispatches an HTTPS webhook payload to Azure DevOps (https://dev.azure.com/{org}/_apis/public/hooks/externalEvents). Azure Pipelines evaluates branch and path triggers and schedules the pipeline on an agent pool.

# Azure Pipelines YAML triggered from an external GitHub repository
resources:
  repositories:
    - repository: ExternalGitHubRepo
      type: github
      name: ContosoCorp/PaymentEngine
      endpoint: ContosoGitHubServiceConnection
      trigger:
        branches:
          include:
            - main
            - releases/*

Deploying to Azure from GitHub Actions via OpenID Connect (OIDC)

Storing long-lived Azure Service Principal passwords or client secrets inside GitHub Secrets creates a substantial security risk. The industry standard and AZ-400 recommended pattern is Workload Identity Federation via OpenID Connect (OIDC).

[GitHub Actions Runner] ──────1. Request OIDC Token──────► [GitHub OIDC Token Service]
          │                                                         │
          │                                                   2. Issues JWT
          │                                                         │
          ▼                                                         ▼
[azure/login Action] ────────3. Exchange JWT for Token────► [Microsoft Entra ID]
          │                                                         │
          │                                                   4. Validates Subject Ref
          ▼                                                         ▼
[Azure CLI / ARM Deploy] ────5. Authorize with Short-Lived Access Token──► [Azure Subscription]

Configuration Workflow:

1. Microsoft Entra ID App Registration: Register an application representing the GitHub workflow.
2. Federated Identity Credential: Create a federated credential linking the application to the GitHub repository subject identifier:
   • Issuer: https://token.actions.githubusercontent.com
   • Subject Identifier: repo:<org>/<repo>:ref:refs/heads/main (or environment:<env-name>)
   • Audience: api://AzureADTokenExchange
3. Role Assignment: Assign Azure RBAC roles (e.g., Contributor) to the App Registration on the target resource group or subscription.
4. GitHub Actions Workflow: Authenticate seamlessly without secrets:

   name: Deploy to Azure via OIDC
   on:
     push:
       branches: [ main ]
   permissions:
     id-token: write # Mandatory for requesting the OIDC JWT token
     contents: read
   jobs:
     deploy:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
         - name: Azure Login via OIDC
           uses: azure/login@v2
           with:
             client-id: ${{ secrets.AZURE_CLIENT_ID }}
             tenant-id: ${{ secrets.AZURE_TENANT_ID }}
             subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
         - name: Deploy ARM Template
           uses: azure/arm-deploy@v1
           with:
             resourceGroupName: 'rg-production-eastus'
             template: './infra/main.bicep'
   

---

2. Migration Strategies: Azure Pipelines to GitHub Actions

Migrating legacy pipelines requires a systematic translation of tasks, variables, and governance constructs.

Translating Common Tasks to Actions

Variable and Secret Mapping

• Azure DevOps Variable Groups (linked to Azure Key Vault) map to GitHub Actions Environment Secrets or dynamic retrieval at runtime using the azure/get-keyvault-secrets@v1 action.
• Pipeline Parameters (parameters:) in Azure Pipelines map to workflow_dispatch inputs in GitHub Actions.
• Stage Dependencies (dependsOn) map to Job Dependencies (needs:).
• Pipeline Templates (template: steps.yml) map to Composite Actions (for modular steps) or Reusable Workflows (workflow_call for entire jobs).

---

3. Connecting GitHub Repositories to Azure Pipelines

Azure Pipelines can build a GitHub repository through three different connection types, and the exam expects you to know which one survives an employee departure:

The GitHub App is organization-scoped and can be restricted to selected repositories, so the pipeline keeps building after the person who created the connection leaves. OAuth and PAT connections are bound to one human identity and are the standard cause of "the pipeline stopped triggering after an offboarding" scenarios.

Two more integration mechanics show up repeatedly:

• Multi-repository checkout. A pipeline stored in Azure Repos can build source from GitHub by declaring the repository as a resource and checking it out explicitly:

resources:
  repositories:
    - repository: appSource
      type: github
      name: contoso/payments-api
      endpoint: contoso-github-app   # service connection name
      ref: refs/heads/main

steps:
  - checkout: self
  - checkout: appSource

• Branch protection integration. For GitHub repositories the gate is the GitHub branch protection rule / ruleset that marks the Azure Pipelines check as required. There is no Azure DevOps branch policy for a GitHub branch, which is the mirror image of the Azure Repos rule where YAML pr: triggers are ignored in favour of branch policies.

---

4. Realistic Exam Scenario & Common Traps

Scenario: Enterprise Financial Portal Modernization

Organization: Woodgrove Bank maintains 40 core banking services. Developers write code in GitHub Enterprise Cloud. However, internal banking compliance mandates that no deployment to production can proceed without:

1. A validated ServiceNow change request ticket.
2. Sign-off from the Head of InfoSec.
3. Automatic rollback if error rates exceed 0.5% in Azure Monitor within 15 minutes of release.
4. Complete audit traceability linked to formal security test plans in Azure Test Plans.

DevOps Solution:

• Retain Azure Pipelines as the enterprise release orchestration engine.
• Configure a GitHub Service Connection using the Azure Pipelines GitHub App so pushes in GitHub Enterprise trigger Azure Pipelines builds.
• Implement an Azure Pipelines YAML multi-stage pipeline where the DeployProd stage targets an Azure DevOps Environment named Production-CoreBanking.
• Configure Environment Checks: an Invoke REST API check to validate the ServiceNow ticket, a Manual Approval assigned to InfoSec, and an Azure Monitor Alerts gate evaluating live application telemetry.
• Maintain code in GitHub for optimal developer experience while preserving enterprise compliance and governance in Azure DevOps.

Common Exam Traps to Avoid

• Trap: Believing GitHub Actions requires storing long-lived service principal passwords. Storing client secrets in GitHub Secrets is vulnerable to expiration and leakage. Microsoft strongly recommends OIDC Workload Identity Federation (azure/login@v2 with id-token: write).
• Trap: Assuming GitHub Actions natively supports TFVC or Subversion. GitHub Actions only runs against Git repositories. If an exam scenario mentions TFVC, Azure Pipelines is the mandatory answer.
• Trap: Conflating Classic Release Gates with YAML Environment Checks. Classic release pipelines use pre/post-deployment gates on release stages. YAML multi-stage pipelines enforce gates exclusively via Checks & Approvals configured on Environments in Project Settings.