GitHub and Azure DevOps: who can do what, and how they work together

Nordlicht Reisen GmbH, a fictional travel agency, has so far maintained its booking portal in a single tool. Now two teams are joining, and each has its own habits: one team lives on GitHub, the other has its task planning in Azure Boards. The head of engineering wants to know whether that is a problem. The answer of the AZ-400 exam is: no problem, if you know both worlds and know who can do what and how they work together.

This lesson is the map of the course. It does not teach any operation yet, but puts things in order: which services exist on both sides, what the terms are called there, which combinations are common, and how you decide what belongs where. The later lessons go deeper into every point.

Prior knowledge: K3 teaches pipelines for a .NET application: GitHub Actions in lesson 3.7.1, Azure Pipelines with YAML, templates and variable groups in lesson 3.7.2. There you already know the building blocks trigger, pool, stages, jobs and steps, and that an agent is called a runner on GitHub. Here we use that as a springboard for the comparison. The course does not repeat those lessons.

Note: All statements come from the documentation of Microsoft Learn and of GitHub; the pages are listed under "Further reading". The commands and YAML files of this lesson were not run; they come from the reference of Microsoft and GitHub.

The services of both worlds side by side

Azure DevOps is Microsoft's platform for software teams. It consists of five services, which Microsoft describes like this: Azure Boards (work planning), Azure Repos (source code), Azure Pipelines (build and release), Azure Test Plans (planned and exploratory testing) and Azure Artifacts (package feeds). In addition there are a wiki and dashboards. The top-level organizing concept is the project; there you can switch the services on and off individually.

GitHub has cut the same tasks differently. GitHub's introduction lists: repositories, issues and milestones for planning, Projects for managing projects, pull requests for changes, automated workflows for testing and deployment, Packages for publishing software packages, security features and Discussions.

Two rows deserve a second look. Test Plans is not a dedicated service on GitHub: whoever wants to plan manual tests and link them to requirements and bugs uses Test Plans in Azure DevOps (Microsoft names there the linking of requirements to test cases and bugs, queries for test suites and a table-like interface). And for security, the same product family exists on both sides; how it fits together is taught in lesson 5.4.

The structure: account, organization, project, repository

The structure differs, and the exam asks about it:

Remember the difference between repository and project: an Azure DevOps project can contain many repositories and has boards and pipelines in common for all of them. A GitHub repository contains its code, its issues and its workflows; a GitHub organization brings many repositories together.

For identity, Microsoft states: Azure DevOps organizations can be connected to Microsoft Entra ID when you sign in with a work or school account; the organization is then connected automatically. Customers of GitHub Enterprise Cloud who sign in to GitHub and Azure DevOps with the same Microsoft Entra tenant get the access level GitHub Enterprise in Azure DevOps at no extra charge; Azure DevOps checks this at the first sign-in and every 24 hours after that. Only users of GitHub Enterprise Cloud are recognized, not those of GitHub Enterprise Server.

Translating the terms

Whoever moves from one world to the other stumbles over names first. GitHub's migration guide from Azure Pipelines to GitHub Actions maps the most important terms:

Three notes from the same page belong here. First: GitHub Actions requires you to split stages into separate YAML workflow files. Second: the default shell on Windows is cmd.exe in Azure Pipelines and PowerShell in GitHub Actions; whoever needs the behavior of cmd sets shell: cmd. Third: GitHub Actions requires explicit job definitions, so even a pipeline with only one job needs a full jobs: block. The page does not map templates, reusable workflows, variables, secrets and environments; they come in lessons 4.4, 4.7 and 5.3.

A small example shows the translation. First the Azure Pipelines version:

jobs:
  - job: build
    steps:
      - script: dotnet build --configuration Release
  - job: test
    dependsOn: build
    condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
    steps:
      - script: dotnet test

And the same intent as a GitHub Actions workflow:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: dotnet build --configuration Release
  test:
    needs: build
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: dotnet test

The pipeline lists job names as job: in a list, the workflow names them as keys of jobs:. The workflow names the runner with runs-on and fetches the code with a separate step (actions/checkout); the pipeline names its pool elsewhere (pool, lesson 3.7.2 from K3). Lesson 3.7.1 from K3 showed this for an application; here the mapping is enough for you.

How both work together

In practice, everything rarely runs in one world. Microsoft describes the connection points on the page "About GitHub integration". There are four common combinations:

Azure Boards and GitHub

For the integration of Azure Boards and GitHub, Microsoft names these functions: link work items with commits, pull requests, branches and issues; open linked objects on the board; see pull requests (draft, review status, status of the checks) in the "Development" section of a work item; mention pull requests with ! in texts; automatically create "Integrated in build" links for YAML pipelines; put status badges of Azure Boards in the README file of a GitHub repository; and synchronize GitHub issues with work items of Azure Boards using a GitHub Action. How that works is taught in lessons 1.1 and 1.2.

The connection runs through the Azure Boards app for GitHub. It authenticates and acts as an app instead of as an individual person; according to Microsoft, the advantage over older ways with OAuth or a personal access token is that team members can change without the connection depending on a single person.

Azure Pipelines and GitHub

Azure Pipelines can build, test, package and deliver the code of a GitHub repository. Microsoft names: builds for pull requests with feedback as a comment in the pull request, manual starting by comment in the pull request, checking drafts (drafts in the pr trigger), restarting failed builds, builds of pull requests from forks, GitHub-specific tasks such as "GitHub Release" and "Download GitHub Release", build tags for tracing sources. Connecting a repository to Azure Pipelines and the trigger rules are taught in lesson 4.1.

For GitHub Enterprise Server, Microsoft says there are differences: there is no app like the one for GitHub.com, you need a personal access token, user name and password, or OAuth; the protections for contributions from forks (for example, no secrets passed to running jobs) are not available; comment triggers and GitHub Checks do not exist, status reports are simple statuses.

Tools of the other world even without a connection

Finally, note two things that do not depend on the connection. Azure Pipelines cannot replace GitHub Actions and vice versa; both run side by side, and a repository can have workflows and a pipeline. And the security of every connection depends on the permissions: a service connection to Azure, an app installation on GitHub, an access token. Lesson 5.1 covers this.

Choosing a deployment automation solution

The exam asks: which solution fits which requirement? For the toolchain of Azure Landing Zones, Microsoft gives a recommendation that serves as a starting point:

• GitHub Enterprise with repository, GitHub Advanced Security and GitHub Advanced Security for Azure DevOps as the foundation for code and security.
• GitHub Actions for automation, if the repositories are on GitHub.
• Azure Pipelines for more complex scenarios: when code from outside GitHub is needed or central management of workflow templates and build pipelines is required.
• Azure Boards for planning, integrated with Azure Pipelines for GitHub repositories.
• GitHub Packages for packages and container images, Azure Artifacts for a feed with review, permissions and an audit log.

That is a draft, not an obligation. The decision table sums it up:

For identity, the practical rule is: for Azure DevOps Services, Microsoft recommends sign-in through Microsoft Entra as the default, for users as well as for automation. Which identity is suited for what is taught in lesson 5.1.

Cost and clean-up

This lesson creates nothing in Azure and nothing that costs money over time. The exercises work with paper and with a small example on your machine.

• If you created a repository in Exercise 2, delete it again after the exercise (lesson 0.1: delete a repository, check with gh repo view).
• If you created an Azure DevOps project, delete it or keep it for module D1. It stays free within the free tier.

jobs:
  - job: pruefen
    steps:
      - script: dotnet format --verify-no-changes
  - job: bauen
    dependsOn: pruefen
    condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
    steps:
      - script: dotnet build --configuration Release

jobs:
  pruefen:                      # job: pruefen
    runs-on: ubuntu-latest      # in Azure Pipelines: pool
    steps:
      - uses: actions/checkout@v4          # fetches the code (uses: instead of task:)
      - run: dotnet format --verify-no-changes   # script:
  bauen:
    needs: pruefen              # dependsOn:
    if: github.ref == 'refs/heads/main'   # condition: eq(...)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: dotnet build --configuration Release

Typical mistakes

• Expecting stages as a keyword in GitHub Actions. GitHub Actions has no stages; the guide says to split stages into separate workflow files.
• Windows scripts behave differently. Azure Pipelines uses cmd.exe on Windows, GitHub Actions uses PowerShell; whoever needs the old behavior sets shell: cmd.
• A single job without a jobs: block. GitHub Actions requires explicit job definitions, even with only one job.
• The Boards connection shows an empty list of repositories. According to Microsoft, this is often because the GitHub organization has restricted access for third-party apps or access for the app to the organization has not been granted yet (status "Access request pending"). An organization owner or administrator must grant it.
• Connecting one GitHub repository to several Azure DevOps organizations. Microsoft advises against it: it can lead to unexpected links with AB#.

What you can do now

You match the services of GitHub and Azure DevOps to each other and know the structure of both worlds: account and organization, repository and project. You translate terms such as agent and runner, dependsOn and needs, task and uses. You know the four combinations of both tools and the integrations between Azure Boards, Azure Pipelines and GitHub, including the limits with GitHub Enterprise Server. And you justify the choice of a solution for automating deployment with Microsoft's recommendation: GitHub Actions when the repositories are on GitHub, Azure Pipelines for complex scenarios and central templates.

Further reading

• What is Azure DevOps?: https://learn.microsoft.com/azure/devops/user-guide/what-is-azure-devops
• About GitHub integration: https://learn.microsoft.com/azure/devops/cross-service/github-integration
• What is the Azure Boards-GitHub integration?: https://learn.microsoft.com/azure/devops/boards/github/
• Build GitHub Enterprise Server repositories: https://learn.microsoft.com/azure/devops/pipelines/repos/github-enterprise
• DevOps toolchain (Azure Landing Zones): https://learn.microsoft.com/azure/cloud-adoption-framework/ready/considerations/devops-toolchain
• Authentication guidance for Azure DevOps: https://learn.microsoft.com/azure/devops/organizations/security/authentication-guidance
• User and permissions management FAQs: https://learn.microsoft.com/azure/devops/organizations/accounts/faq-user-and-permissions-management
• Migrating from Azure Pipelines to GitHub Actions: https://docs.github.com/en/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-azure-pipelines-to-github-actions
• About GitHub and Git: https://docs.github.com/en/get-started/start-your-journey/about-github-and-git