Integrate Azure DevOps with GitHub: Complete Setup Walkthrough

Integrating Azure DevOps and GitHub is rarely just a “connect the repo and run a build” task for IT administrators. In practice, you are joining two identity, permission, and audit domains—each with its own expectations about how code changes are authorized and how automation is allowed to act. The goal is usually to keep GitHub as the developer-facing collaboration surface (issues, pull requests, reviews), while using Azure DevOps where it is strongest for many enterprises: Azure Pipelines for CI/CD, environments and approvals for release control, and tight integration with Azure resources.

This guide walks through a production-oriented approach to integrate Azure DevOps with GitHub. It focuses on predictable permissions, secure authentication (including modern approaches that reduce long-lived secrets), and repeatable pipeline patterns. You will see how to connect GitHub repositories to Azure Pipelines, validate pull requests (PRs) with branch protection, and deploy to Azure with environment controls—while staying mindful of what administrators typically care about: least privilege, auditability, and operational clarity.

Integration patterns: what you are actually trying to connect

Before you touch a setting, it helps to decide which integration pattern you want. “Azure DevOps + GitHub” can mean multiple things, and the operational consequences differ.

The most common pattern is GitHub for source control (GitHub.com or GitHub Enterprise Cloud/Server) and Azure Pipelines for CI/CD. In this setup, GitHub remains the system of record for the repository, and Azure DevOps is primarily a pipeline runner, a release gatekeeper, and a place to centralize build/deploy logs.

Another pattern is GitHub for code + Azure DevOps for work tracking. This is feasible but introduces additional complexity because you are now syncing work items and PR context. It can be done, but it is not necessary for a solid CI/CD integration, and many teams avoid it unless they have a strong process requirement.

A third pattern is the “hybrid legacy” model: some repos live in Azure Repos, while others are in GitHub. Azure DevOps can build from both. Administratively, this often appears during migrations and acquisitions. If that sounds like your environment, your main challenge is to standardize pipeline templates and security controls across both repository providers.

In the remainder of this walkthrough, the primary assumption is: GitHub hosts the repository, Azure DevOps runs the pipelines, and deployments target Azure.

Prerequisites and planning (the admin checklist that prevents rework)

Integration tends to fail later not because the YAML is wrong, but because identity and permissions were not agreed up front. The items below are the practical prerequisites that keep the rest of the setup predictable.

You need an Azure DevOps organization and a project that will own the pipelines. In Azure DevOps, permissions and service connections are scoped to a project, and administrators typically want a clear ownership boundary for automation.

You also need a GitHub organization/repository and enough rights to install or authorize an integration (depending on which connection method you use). In many enterprises, GitHub org administrators control app installations; repository administrators may not be able to authorize external pipeline systems.

On the Azure side, you should identify the Azure subscriptions and resource groups the pipeline will touch. If deployments are part of the integration, decide whether you will use a service principal (classic), a workload identity federation / OIDC-style approach (modern), or an environment-specific deployment identity. Your decision affects secret storage, rotation, and audit posture.

Finally, decide whether you will use Microsoft-hosted agents or self-hosted agents for Azure Pipelines. Microsoft-hosted agents are operationally simple but have limitations (network access to private endpoints, custom tooling, long-running jobs). Self-hosted agents require lifecycle management and hardening but give you predictable network access and tooling.

Authentication and connectivity: choosing the right GitHub connection method

Azure Pipelines can connect to GitHub using different mechanisms, and administrators should choose based on governance, auditability, and operational overhead.

The historically common approach is an OAuth-based service connection, where a user authorizes Azure DevOps to access GitHub resources. This is quick to set up but has a real operational downside: the token can become tied to a person’s account and may break when that person leaves, changes permissions, or is subject to stricter token policies.

A more enterprise-friendly model is to use a GitHub App-based connection (where available), which is installed at the organization or repository scope and grants explicit permissions. GitHub Apps are easier to reason about: permissions are visible, installation scope is controllable, and the integration is less likely to be disrupted by user lifecycle events.

Which one you should prefer depends on your GitHub governance. If you can install a GitHub App and manage it like a first-class integration asset, that is usually the better long-term option. If you cannot, OAuth works, but you should treat it as a transitional mechanism and document ownership and break-glass procedures.

Creating the GitHub service connection in Azure DevOps (securely)

From an Azure DevOps project, you create a service connection to GitHub so pipelines can fetch code and create webhooks for PR and push triggers. Service connections are a security boundary: they decide what external system a pipeline can interact with.

In Azure DevOps, go to Project settings → Service connections and create a new connection for GitHub. If your environment offers a GitHub App flow, follow that and install/authorize the app for the specific org/repositories needed. Limit scope to what you need. Avoid granting “all repositories” unless you have a clear reason and compensating controls.

If you must use OAuth, ensure the account authorizing the connection is a non-personal integration account (for example, a managed “build” user) that is subject to your organization’s MFA and token governance, and that its membership is maintained by an admin-owned group rather than ad hoc invites.

After creating the connection, decide whether to allow all pipelines to use it or require explicit authorization. In many organizations, you should not allow “grant access permission to all pipelines” for a broadly scoped GitHub connection. Instead, explicitly authorize it per pipeline. This reduces the blast radius if a pipeline is modified maliciously.

Wiring GitHub triggers to Azure Pipelines: webhooks, PRs, and branch protection

Once the service connection is in place, Azure Pipelines can create GitHub webhooks so that pushes and PR updates trigger runs. For administrators, the key is to align this automation with GitHub’s branch protection rules.

A typical pattern is:

Use Azure Pipelines for CI on every PR and on pushes to protected branches.
Use GitHub branch protection to require the Azure Pipelines status checks to pass before merge.
Keep the workflow YAML in the repository so it is versioned and reviewed like any other change.

This creates a clean audit chain: the change is proposed via PR, validated by the pipeline, and merged only when checks and reviews succeed.

Azure Pipelines supports PR triggers in YAML. If you are using GitHub as the repo, the PR concept and branch names are still Git-based; Azure Pipelines listens to GitHub events. Your validation pipeline should be fast and deterministic: linting, unit tests, static analysis, and packaging. The goal is to prevent obvious regressions from entering protected branches.

Building your first Azure Pipeline for a GitHub repo (YAML-based)

A common first pipeline is a CI build that runs on PRs and main branch pushes. In Azure Pipelines, you can create a new pipeline, select GitHub as the source, choose the repository, and let it generate a starter YAML.

Treat that starter YAML as a scaffold, not a final answer. Administrators should ensure the pipeline:

Uses a supported agent image.
Pins critical tool versions when possible.
Publishes artifacts in a consistent way.
Avoids printing secrets.

Below is an example azure-pipelines.yml for a Node.js service. It runs on PRs and pushes to main, caches dependencies for speed, runs tests, and publishes a build artifact.

trigger:
  branches:
    include:
      - main

pr:
  branches:
    include:
      - main
      - feature/*

pool:
  vmImage: 'ubuntu-latest'

variables:
  NODE_VERSION: '20.x'

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '$(NODE_VERSION)'
    displayName: 'Use Node.js $(NODE_VERSION)'

  - script: |
      npm ci
    displayName: 'Install dependencies'

  - script: |
      npm test
    displayName: 'Run unit tests'

  - script: |
      npm run build
    displayName: 'Build'

  - task: PublishPipelineArtifact@1
    inputs:
      targetPath: '$(System.DefaultWorkingDirectory)'
      artifact: 'drop'
      publishLocation: 'pipeline'
    displayName: 'Publish build artifact'

The important integration point is that this YAML lives in GitHub, but the pipeline runs in Azure DevOps. That means the pipeline’s identity and permissions (service connections, variable groups, environment approvals) are still governed in Azure DevOps.

Aligning GitHub branch protection with Azure Pipelines status checks

After the pipeline runs successfully at least once, GitHub can require it as a status check. This is where administrators can enforce that PRs cannot merge unless Azure Pipelines reports success.

In GitHub repository settings, configure Branch protection rules for your protected branch (often main). Require pull request reviews and require status checks to pass before merging. Then select the Azure Pipelines checks that correspond to your pipeline.

This is not just a developer convenience. It is a policy control. When implemented properly, the only way into your protected branch is via a PR that has the required reviews and a passing build. That reduces the risk of “hotfix pushes” bypassing validation.

One operational nuance: if you later rename the pipeline or re-create it, GitHub may see a different check name. Plan pipeline naming conventions early so you don’t create churn in branch protection.

Real-world example 1: Enforcing PR validation for a shared platform library

Consider a platform team maintaining a shared Terraform module library used by dozens of product teams. The repo is in GitHub because that’s where teams collaborate, but the organization requires all CI logs and artifact retention to be centralized in Azure DevOps.

In this scenario, the platform team sets up an Azure Pipeline that runs terraform fmt -check, terraform validate, and a static analysis tool on every PR. GitHub branch protection requires the Azure Pipeline check plus at least one platform-team review. This gives product teams fast feedback while ensuring the platform team retains control over what merges.

The key administrative benefit is audit consistency: regardless of which product team submits changes, validation is executed by Azure Pipelines under a controlled identity, and results are retained under Azure DevOps retention policies.

Managing secrets and variables: keep sensitive data out of GitHub and YAML

As soon as pipelines deploy anywhere, you must decide where secrets live. A secure integration avoids committing secrets in GitHub and avoids plaintext pipeline variables.

In Azure DevOps, you can use variable groups to store values and mark secrets as secret. Secret variables are masked in logs. However, variable groups still store secrets inside Azure DevOps; you need to manage access and rotation.

A stronger pattern is to store secrets in Azure Key Vault and let Azure Pipelines retrieve them at runtime. This reduces secret sprawl and centralizes rotation. Access can be granted to the pipeline identity, and the Key Vault provides audit logs.

If you do use Key Vault, keep in mind that you are now integrating three systems: GitHub (source), Azure DevOps (orchestration), and Azure (secrets). The pipeline must have a way to authenticate to Azure to fetch secrets, which brings us to deployment authentication options.

Deploying to Azure from a GitHub-based Azure Pipeline: identity options

To deploy to Azure, your pipeline needs an Azure identity. Traditionally, this is an Azure AD application/service principal with a client secret or certificate. That works, but it introduces secret rotation and the risk of credential leakage.

Modern Azure deployments increasingly use workload identity federation (often discussed as OIDC). The general idea is to avoid storing a long-lived client secret in the pipeline. Instead, the pipeline obtains a short-lived token based on its runtime identity and exchanges it for an Azure token. This reduces the impact of leaked credentials.

In Azure DevOps specifically, the availability and setup of workload identity federation can vary by environment and feature set. If you cannot adopt federated credentials in your org today, a service principal with a certificate stored in Key Vault is typically safer than a long-lived client secret embedded in a variable group.

Regardless of identity type, follow least privilege: scope permissions to the smallest set of subscriptions/resource groups and roles required (for example, Contributor on a specific resource group, or more granular roles where possible).

Creating an Azure service connection for deployments

Azure Pipelines uses Azure Resource Manager service connections to authenticate to Azure. Create one in Project settings → Service connections.

If you use a service principal, create or select an app registration and grant it access to the target subscription/resource group. For least privilege, prefer scoping the service connection to a resource group when the UI supports it, and avoid “full subscription” unless necessary.

Administrators should also control who can use the service connection. In Azure DevOps, you can restrict service connection usage to specific pipelines and specific users/groups. This is an important control because anyone who can modify a pipeline that uses a powerful service connection can potentially deploy or exfiltrate resources.

Once created, you will reference the service connection name in your YAML.

A practical deployment pipeline: build once, deploy many

A reliable enterprise pipeline separates CI from CD. You build artifacts once, sign/version them, and deploy the same artifact to environments (dev/test/prod) with approvals and checks.

Azure DevOps supports this with multi-stage YAML pipelines and environments. An environment can represent “dev” or “prod” and can enforce approvals, checks, and deployment history. For administrators, environments are a governance feature: they provide a place to define who can approve production deployments.

Below is a simplified multi-stage pipeline that builds an artifact and deploys an Azure Web App using Azure CLI. This example assumes you already have an Azure service connection and a resource group/app.

yaml
trigger:
  branches:
    include:
      - main

pr:
  branches:
    include:
      - main

pool:
  vmImage: 'ubuntu-latest'

stages:
- stage: Build
  displayName: Build
  jobs:
  - job: Build
    steps:
    - script: |
        echo "Build step goes here"
      displayName: 'Build'

    - task: PublishPipelineArtifact@1
      inputs:
        targetPath: '$(System.DefaultWorkingDirectory)'
        artifact: 'drop'

- stage: Deploy_Dev
  displayName: Deploy to Dev
  dependsOn: Build
  condition: succeeded()
  jobs:
  - deployment: Deploy
    environment: 'dev'
    strategy:
      runOnce:
        deploy:
          steps:
          - task: DownloadPipelineArtifact@2
            inputs:
              artifact: 'drop'
              path: '$(Pipeline.Workspace)/drop'

          - task: AzureCLI@2
            inputs:
              azureSubscription: 'sc-azurerm-dev'
              scriptType: 'bash'
              scriptLocation: 'inlineScript'
              inlineScript: |
                az webapp deployment source config-zip \
                  --resource-group rg-dev \
                  --name webapp-dev \
                  --src "$(Pipeline.Workspace)/drop/app.zip"

In a production pipeline, you would add additional stages for test and prod, with environment approvals configured in Azure DevOps. Even though GitHub hosts the code, the release governance lives in Azure DevOps, which is often desirable in regulated environments.

Real-world example 2: Regulated production releases with GitHub PRs and Azure approvals

A financial services team keeps repositories in GitHub to support external collaboration and code scanning workflows. However, production deployments must be approved by an on-call release manager and recorded in a centralized system.

They implement a multi-stage Azure Pipeline triggered by merges to main. The dev stage runs automatically, while prod is tied to an Azure DevOps environment named prod that requires two approvers from the SRE group. GitHub branch protection ensures all PRs have security review and passing CI, while Azure DevOps ensures production deployments have explicit approvals and are auditable.

The integration is effective because it splits responsibilities cleanly: GitHub governs code changes, Azure DevOps governs runtime change control.

Using reusable pipeline templates across many GitHub repositories

At scale, you will quickly run into a maintainability problem: dozens or hundreds of GitHub repositories, each with their own azure-pipelines.yml, diverge over time. Administrators typically want standardized pipelines for consistent controls (scanning, signing, artifact retention) while still allowing repo-specific build steps.

Azure Pipelines supports YAML templates that can be stored in a central repository. Even if your application repositories are in GitHub, your template repository can be in Azure Repos or GitHub. The key is to control access to the template repo because it effectively controls how pipelines run.

A common pattern is to store templates in an internal repo and reference them from application repos. You can define a base template that includes security scanning tasks, standardized artifact publishing, and consistent naming.

Example structure:

org-pipeline-templates repo: contains templates/ci.yml, templates/deploy.yml
Application repo: azure-pipelines.yml references templates and passes parameters

A simple template reference might look like:

yaml
resources:
  repositories:
    - repository: templates
      type: github
      name: YourOrg/org-pipeline-templates
      endpoint: sc-github-templates

extends:
  template: templates/ci.yml@templates
  parameters:
    nodeVersion: '20.x'

This approach tightens governance: you can update controls centrally, and teams inherit updates with a controlled change process.

Agent strategy: Microsoft-hosted vs self-hosted in an enterprise network

Integration planning is incomplete without an agent strategy. With GitHub as the repo and Azure DevOps as the pipeline runner, the agent is the execution environment that needs outbound access to GitHub, Azure DevOps, and possibly internal resources.

Microsoft-hosted agents are convenient: they can reach GitHub and Azure APIs easily, come with a broad set of tools, and reduce operational toil. However, they typically cannot reach internal services behind private networks unless you expose them via public endpoints or configure additional networking patterns.

Self-hosted agents are the usual answer when builds require access to on-prem resources, private package feeds, or private Azure endpoints. Administratively, this requires patching, monitoring, scaling, and security hardening. Treat self-hosted agents like servers: restrict interactive logon, isolate them per trust boundary, and ensure they cannot be repurposed to exfiltrate secrets.

A practical middle ground is to use Microsoft-hosted agents for most CI work (linting, unit tests) and self-hosted agents only for steps that require network proximity (integration tests against internal systems, deployments into locked-down environments).

Hardening the integration: permissions, pipeline security, and change control

Once the first pipeline works, the next concern is preventing the integration from becoming a privilege-escalation path. A pipeline that can deploy to production is effectively a privileged automation identity, and GitHub contributors can potentially modify YAML.

Start by limiting who can modify the default branch in GitHub via branch protection, required reviews, and code owner rules. This ensures that pipeline YAML changes receive review.

In Azure DevOps, restrict who can edit pipelines and who can authorize service connections. Use the “pipeline permissions” model to limit which pipelines can use powerful connections. For environments, use approvals and checks to protect deployment stages.

Also pay attention to pull request builds. In many CI systems, PRs from forks can be dangerous because untrusted contributors can modify pipeline code. If you accept external contributions, design PR validation so it does not expose secrets and does not run privileged deployment steps. Keep deployment stages conditioned on trusted branches.

A common control is to ensure that the pipeline does not have access to production service connections or secret variable groups when building untrusted PRs. Structure your YAML so that secret-consuming steps run only on protected branches.

Working with GitHub Enterprise Server (GHES) and private connectivity

If you use GitHub Enterprise Server, integration details can differ from GitHub.com. The primary administrative differences are network reachability, TLS/certificate trust, and webhook delivery.

Your Azure Pipelines agent must be able to reach the GHES instance. If you use Microsoft-hosted agents, that implies the GHES instance must be reachable from the public internet (often not acceptable). In practice, GHES integrations usually require self-hosted agents with network access to GHES.

You also need to ensure the agent trusts the TLS certificate chain used by GHES. If your organization uses an internal CA, install the CA certificates on the agent machines so Git operations succeed.

Webhook delivery from GHES to Azure DevOps also requires network paths. If inbound connectivity is restricted, you may need to rely on alternative triggering mechanisms or ensure outbound webhook traffic is allowed. Because these designs are environment-specific, it’s common to validate with a minimal pipeline first—fetch code and run a basic script—before investing in full release pipelines.

Real-world example 3: On-prem GitHub Enterprise Server with self-hosted agents

A manufacturing company runs GitHub Enterprise Server on-prem for IP protection and uses Azure DevOps in Azure for CI/CD governance. Their build agents run in a DMZ network segment that can reach both GHES and Azure DevOps but has tightly controlled outbound internet access.

They configure a self-hosted agent pool in Azure DevOps and ensure the agents trust the GHES certificate chain. The CI pipeline runs build and unit tests and publishes artifacts to Azure DevOps. Deployments to Azure run from the same agent pool, using an Azure service connection scoped to a single resource group per environment.

This setup works because it respects the network boundary: code never needs to be mirrored to a public GitHub, and the build system does not require broad internet access, but Azure DevOps still provides centralized pipeline governance.

Integrating GitHub checks and Azure DevOps pipeline naming conventions

Administrators often underestimate how confusing status checks become as pipelines multiply. GitHub displays checks by name, and teams will quickly ask which one is required.

Choose a naming convention that encodes purpose and scope, such as:

ci/<repo> for PR validation
cd/dev/<repo> for dev deployments
cd/prod/<repo> for production deployments

In Azure DevOps, align pipeline names with these checks. Keep names stable, because GitHub branch protection rules reference check names. If you must rename, plan a controlled change: update branch protection rules during a maintenance window to avoid blocking merges.

Working with mono-repos and path filters

If your GitHub repository is a mono-repo, you might want different pipelines per service, or at least limit runs to changes in certain paths. Azure Pipelines supports path filters for triggers.

Path filters reduce noise and cost, but they also have governance implications. If a change outside a path can still affect the build (for example, shared libraries), overly aggressive filtering can let regressions slip in. Use path filters where boundaries are strong and well-understood.

A basic trigger with path filters might look like:

yaml
trigger:
  branches:
    include:
      - main
  paths:
    include:
      - services/api/**
      - pipelines/api/**

pr:
  branches:
    include:
      - main
  paths:
    include:
      - services/api/**
      - pipelines/api/**

Over time, treat path filters as part of architecture governance: if services are not truly independent, avoid fragmenting CI.

Artifact retention, logs, and compliance considerations

One reason enterprises prefer Azure DevOps for pipelines even when code is in GitHub is retention and compliance. Azure DevOps provides build logs, artifact retention policies, and environment deployment histories that can satisfy audit requirements.

Set retention policies deliberately. For regulated systems, you might need longer retention for build artifacts and logs, and you may need to ensure artifacts are immutable (for example, by pushing them to an artifact repository with immutability controls). Azure DevOps pipeline artifacts are convenient for stage-to-stage flow, but you may still want to publish final artifacts to a dedicated registry (Azure Artifacts, container registry, or an external artifact store).

Also consider who can access logs and artifacts. Logs can contain sensitive data even when you try to avoid it (hostnames, partial configuration values). Restrict project access and use separate projects for high-sensitivity systems when appropriate.

Coordinating GitHub Actions and Azure Pipelines (when both exist)

Many organizations end up with both GitHub Actions and Azure Pipelines. This can be intentional: GitHub Actions for repo-native workflows (labeling, code scanning, dependency updates), Azure Pipelines for deployments and controlled releases. The key is to avoid duplicating CI in two places without a clear reason.

If you keep both, define a division of responsibilities. For example, let GitHub Actions run lightweight PR checks like formatting and linting, while Azure Pipelines runs the heavier build/test/deploy chain. Then require the right set of checks in branch protection.

Administrators should also consider identity boundaries. GitHub Actions uses GitHub’s runner identity and secrets model; Azure Pipelines uses Azure DevOps service connections and variable groups. Mixing them without clarity can lead to duplicated secrets and inconsistent rotation.

Infrastructure as Code deployment example: Bicep via Azure CLI

To make the integration concrete for system engineers, infrastructure as code (IaC) is a common next step. If your GitHub repo contains Bicep templates, Azure Pipelines can deploy them using Azure CLI.

The pattern is consistent: validate on PRs, deploy on merges to protected branches, and gate production with an environment approval.

Here is a simplified Azure CLI deployment step you can embed in a stage, assuming your service connection is already configured:

yaml
- task: AzureCLI@2
  displayName: 'Deploy Bicep'
  inputs:
    azureSubscription: 'sc-azurerm-dev'
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      az deployment group create \
        --resource-group rg-dev \
        --template-file infra/main.bicep \
        --parameters env=dev

If you use parameter files, ensure they do not contain secrets. Secrets should come from Key Vault or pipeline secret variables injected at runtime.

A controlled promotion model using environments

As your integration matures, you should avoid “deploy straight to prod from main with no gates.” Azure DevOps environments are designed to implement promotion with approvals.

A clean model is:

PR validation: runs on PRs, no secrets, no deployments.
Merge to main: builds and deploys to dev automatically.
Promotion to test/prod: either automatic with checks or manual approval, deploying the same artifact.

In YAML, this often means: build stage produces an artifact once, then each deployment stage downloads it. That reduces “it worked in dev because it rebuilt differently” problems and makes deployments auditable.

Administratively, you can add checks on environments: approval from specific groups, business-hour restrictions, or additional automated checks where applicable. The specifics vary by organization, but the design principle is consistent: GitHub controls what code is eligible, Azure DevOps controls when and how it is released.

Operationalizing: monitoring pipeline health and keeping the integration stable

A working integration needs ongoing care. Pipelines depend on agent images, tool versions, service connection validity, and webhook health.

For Microsoft-hosted agents, be aware that ubuntu-latest and similar images evolve. If a toolchain update can break you, consider pinning to a specific image or explicitly installing/pinning tool versions in the pipeline. For self-hosted agents, define a patching cadence and a way to roll back agent updates.

Service connections should be reviewed regularly. If you use service principals with secrets, document rotation procedures and monitor expiration. If you use Key Vault, ensure access policies/RBAC and firewall rules allow the pipeline to retrieve secrets reliably.

Webhook integration is another stability factor. If triggers stop firing, you need to know whether the webhook still exists, whether it is being delivered, and whether Azure DevOps is accepting it. A practical operational approach is to maintain a lightweight “canary” pipeline that runs frequently and alerts when it stops, so you detect integration failures early.

Governance at scale: multiple repos, multiple teams, and delegated admin

When you integrate Azure DevOps with GitHub across many teams, you need a repeatable governance model. Administrators typically centralize:

Service connection creation and scoping
Agent pool management
Template repositories and policy tasks (scanning, signing)
Environment approvals and production deployment rights

Teams typically own:

Repo content and application build steps
Unit/integration tests
PR review discipline (with CODEOWNERS)

The integration succeeds when it enforces a clear boundary: developers can iterate quickly in GitHub, but privileged deployment capabilities remain controlled through Azure DevOps permissions and environments.

To keep that boundary intact, avoid broadly scoped service connections that any pipeline can use, avoid storing secrets in repositories, and ensure pipeline modifications are subject to review. Over time, standardize pipeline templates so controls are consistent and changes are deliberate.

Integrating Azure DevOps with GitHub: End-to-End Setup for Repos and Pipelines