GitHub und Azure DevOps: wer kann was, und wie spielen sie zusammen

Die Nordlicht Reisen GmbH hat ihr Buchungsportal bisher in einem einzigen Werkzeug gepflegt. Jetzt kommen zwei Teams dazu, und beide haben eigene Gewohnheiten: Ein Team lebt bei GitHub, das andere hat seine Aufgabenplanung in Azure Boards. Die Leiterin der Technik will wissen, ob das ein Problem ist. Die Antwort der Prüfung AZ-400 lautet: kein Problem, wenn Sie beide Welten kennen und wissen, wer was kann und wie sie zusammenspielen.

Diese Lektion ist die Landkarte des Kurses. Sie lehrt noch keine Bedienung, sondern ordnet: Welche Dienste gibt es auf beiden Seiten, wie heißen die Begriffe dort, welche Kombinationen sind üblich und woran entscheiden Sie, was wohin gehört. Die späteren Lektionen vertiefen jeden Punkt.

Vorwissen: K3 lehrt Pipelines für eine .NET-Anwendung: GitHub Actions in Lektion 3.7.1, Azure Pipelines mit YAML, Vorlagen und Variablengruppen in Lektion 3.7.2. Dort kennen Sie die Bausteine trigger, pool, stages, jobs und steps bereits, und dass ein Agent bei GitHub Runner heißt. Hier nutzen wir das als Sprungbrett für den Vergleich. Der Kurs wiederholt diese Lektionen nicht.

Hinweis: Alle Angaben stammen aus der Dokumentation von Microsoft Learn und von GitHub; die Seiten stehen unter „Weiterlesen“. Die Befehle und YAML-Dateien dieser Lektion wurden nicht ausgeführt; sie stammen aus der Referenz von Microsoft und GitHub.

Die Dienste beider Welten nebeneinander

Azure DevOps ist Microsofts Plattform für Softwareteams. Sie besteht aus fünf Diensten, die Microsoft so beschreibt: Azure Boards (Arbeitsplanung), Azure Repos (Quellcode), Azure Pipelines (Bauen und Ausliefern), Azure Test Plans (geplantes und exploratives Testen) und Azure Artifacts (Paket-Feeds). Dazu kommen ein Wiki und Dashboards. Der oberste Ordnungsbegriff ist das Projekt; dort lassen sich die Dienste einzeln ein- und ausschalten.

GitHub hat dieselben Aufgaben anders geschnitten. GitHubs Einführung nennt: Repositories, Issues und Milestones für die Planung, Projects zur Verwaltung von Projekten, Pull Requests für Änderungen, automatisierte Workflows für Tests und Bereitstellung, Packages zum Veröffentlichen von Softwarepaketen, Sicherheitsfunktionen und Discussions.

Zwei Zeilen verdienen einen zweiten Blick. Test Plans hat GitHub nicht als eigenen Dienst: Wer manuelle Tests planen und mit Anforderungen und Fehlern verknüpfen will, nutzt in Azure DevOps Test Plans (Microsoft nennt dort die Verknüpfung von Anforderungen mit Testfällen und Fehlern, Abfragen für Testsuiten und eine tabellenartige Oberfläche). Und bei Sicherheit gibt es dieselbe Produktfamilie auf beiden Seiten; wie sie zusammenhängt, lehrt Lektion 5.4.

Die Ordnung: Konto, Organisation, Projekt, Repository

Die Ordnung unterscheidet sich, und die Prüfung fragt danach:

Merken Sie sich den Unterschied zwischen Repository und Projekt: Ein Azure-DevOps-Projekt kann viele Repositories enthalten und hat Boards und Pipelines gemeinsam für alle. Ein GitHub-Repository enthält seinen Code, seine Issues und seine Workflows; eine GitHub-Organisation fasst viele Repositories zusammen.

Für die Identität nennt Microsoft: Organisationen von Azure DevOps lassen sich mit Microsoft Entra ID verbinden, wenn Sie sich mit einem Arbeits- oder Schulkonto anmelden; die Organisation ist dann automatisch verbunden. Kunden von GitHub Enterprise Cloud, die sich bei GitHub und Azure DevOps mit demselben Microsoft-Entra-Mandanten anmelden, bekommen in Azure DevOps die Zugriffsebene GitHub Enterprise ohne zusätzliche Gebühr; Azure DevOps prüft das beim ersten Anmelden und danach alle 24 Stunden. Nur Nutzer von GitHub Enterprise Cloud werden erkannt, nicht die von GitHub Enterprise Server.

Die Begriffe übersetzen

Wer von der einen Welt in die andere wechselt, stolpert zuerst über Namen. GitHubs Migrationsanleitung von Azure Pipelines zu GitHub Actions bildet die wichtigsten Begriffe ab:

Drei Hinweise aus derselben Seite gehören dazu. Erstens: GitHub Actions verlangt, Stufen auf getrennte YAML-Workflow-Dateien aufzuteilen. Zweitens: Die Standard-Shell unter Windows ist bei Azure Pipelines cmd.exe, bei GitHub Actions PowerShell; wer das Verhalten von cmd braucht, setzt shell: cmd. Drittens: GitHub Actions verlangt ausdrückliche Auftragsdefinitionen, also auch für eine Pipeline mit nur einem Auftrag einen vollen jobs:-Block. Die Seite bildet Vorlagen, wiederverwendbare Workflows, Variablen, Geheimnisse und Umgebungen nicht ab; sie kommen in den Lektionen 4.4, 4.7 und 5.3.

Ein kleines Beispiel zeigt die Übersetzung. Zuerst die Azure-Pipelines-Fassung:

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

Und dieselbe Absicht als Workflow von GitHub Actions:

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

Die Pipeline lässt Auftragsnamen als job: in einer Liste stehen, der Workflow benennt sie als Schlüssel von jobs:. Der Workflow benennt den Runner mit runs-on und holt den Code mit einem eigenen Schritt (actions/checkout); die Pipeline nennt ihren Pool an anderer Stelle (pool, Lektion 3.7.2 aus K3). Lektion 3.7.1 aus K3 hat das für eine Anwendung gezeigt; hier genügt Ihnen die Zuordnung.

Wie beide zusammenspielen

In der Praxis läuft selten alles in einer Welt. Microsoft beschreibt die Verbindungspunkte auf der Seite „About GitHub integration“. Es gibt vier übliche Kombinationen:

Azure Boards und GitHub

Microsoft nennt für die Integration von Azure Boards und GitHub diese Funktionen: Arbeitselemente mit Commits, Pull Requests, Branches und Issues verknüpfen; verknüpfte Objekte auf dem Board öffnen; Einblick in Pull Requests (Entwurf, Prüfstatus, Status der Prüfungen) im Abschnitt „Development“ eines Arbeitselements; Pull Requests mit ! in Texten erwähnen; für YAML-Pipelines automatisch „Integrated in build“-Verknüpfungen erzeugen; Statusabzeichen von Azure Boards in die README-Datei eines GitHub-Repositorys setzen; und GitHub Issues mit einer GitHub Action in Arbeitselemente von Azure Boards synchronisieren. Wie das geht, lehren die Lektionen 1.1 und 1.2.

Die Anbindung erfolgt über die App Azure Boards für GitHub. Sie authentifiziert und handelt als App statt als einzelne Person; der Vorteil gegenüber älteren Wegen mit OAuth oder einem persönlichen Zugriffstoken ist laut Microsoft, dass Teammitglieder wechseln können, ohne dass die Verbindung an einer Einzelperson hängt.

Azure Pipelines und GitHub

Azure Pipelines kann den Code eines GitHub-Repositorys bauen, testen, verpacken und ausliefern. Microsoft nennt: Builds für Pull Requests mit Rückmeldung als Kommentar im Pull Request, das manuelle Starten per Kommentar im Pull Request, die Prüfung von Entwürfen (drafts im pr-Trigger), das erneute Starten fehlgeschlagener Builds, Builds von Pull Requests aus Forks, GitHub-spezifische Aufgaben wie „GitHub Release“ und „Download GitHub Release“, Build-Tags zur Nachverfolgung von Quellen. Die Verbindung eines Repositorys mit Azure Pipelines und die Trigger-Regeln lehrt Lektion 4.1.

Für GitHub Enterprise Server gelten laut Microsoft Unterschiede: Es gibt keine App wie die für GitHub.com, Sie brauchen ein persönliches Zugriffstoken, Benutzername und Kennwort oder OAuth; die Schutzmaßnahmen für Beiträge aus Forks (etwa keine Geheimnisse an laufende Aufträge) sind nicht verfügbar; Kommentar-Trigger und GitHub Checks gibt es nicht, Statusmeldungen sind einfache Stati.

Werkzeuge der anderen Welt auch ohne Verbindung

Beachten Sie schließlich zwei Dinge, die nicht von der Verbindung abhängen. Azure Pipelines kann GitHub Actions nicht ersetzen und umgekehrt; beide laufen nebeneinander, und ein Repository kann Workflows und eine Pipeline haben. Und die Sicherheit jeder Anbindung hängt an den Rechten: Eine Dienstverbindung zu Azure, eine App-Installation bei GitHub, ein Zugriffstoken. Lektion 5.1 behandelt das.

Eine Lösung zur Automatisierung der Bereitstellung auswählen

Die Prüfung fragt: Welche Lösung passt zu welcher Anforderung? Microsoft gibt für die Werkzeugkette von Azure Landing Zones eine Empfehlung, die als Ausgangspunkt dient:

• GitHub Enterprise mit Repository, GitHub Advanced Security und GitHub Advanced Security für Azure DevOps als Grundlage für Code und Sicherheit.
• GitHub Actions für die Automatisierung, wenn die Repositories bei GitHub liegen.
• Azure Pipelines für komplexere Szenarien: wenn Code von außerhalb von GitHub gebraucht wird oder eine zentrale Verwaltung von Workflow-Vorlagen und Build-Pipelines nötig ist.
• Azure Boards zur Planung, mit Azure Pipelines für GitHub-Repositories integriert.
• GitHub Packages für Pakete und Container-Images, Azure Artifacts für einen Feed mit Prüfung, Berechtigungen und Prüfprotokoll.

Das ist ein Entwurf, kein Zwang. Die Entscheidungstabelle fasst zusammen:

Für die Identität gilt in der Praxis: Microsoft empfiehlt für Azure DevOps Services als Standard die Anmeldung über Microsoft Entra, für Benutzer wie für Automatisierung. Welche Identität wofür taugt, lehrt Lektion 5.1.

Kosten und Aufräumen

Diese Lektion legt nichts in Azure an und nichts, was nach Zeit kostet. Die Übungen arbeiten mit Papier und mit einem kleinen Beispiel auf Ihrer Maschine.

• Haben Sie in Übung 2 ein Repository angelegt, löschen Sie es nach der Übung wieder (Lektion 0.1: Repository löschen, Probe mit gh repo view).
• Haben Sie ein Azure-DevOps-Projekt angelegt, löschen Sie es oder behalten Sie es für Modul D1. Es bleibt innerhalb der kostenlosen Stufe kostenlos.

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          # holt den Code (uses: statt 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

Typische Fehler

• Stufen als Schlüsselwort in GitHub Actions erwarten. GitHub Actions kennt keine stages; die Anleitung nennt, dass Sie Stufen auf getrennte Workflow-Dateien aufteilen.
• Windows-Skripte laufen anders. Azure Pipelines nutzt unter Windows cmd.exe, GitHub Actions PowerShell; wer das alte Verhalten braucht, setzt shell: cmd.
• Ein einziger Auftrag ohne jobs:-Block. GitHub Actions verlangt ausdrückliche Auftragsdefinitionen, auch bei nur einem Auftrag.
• Die Boards-Verbindung zeigt eine leere Liste von Repositories. Nach Microsoft liegt es oft daran, dass die GitHub-Organisation den Zugriff von Drittanbieter-Apps eingeschränkt hat oder der App der Zugriff auf die Organisation noch nicht gewährt wurde (Status „Access request pending“). Ein Organisationsinhaber oder -administrator muss ihn gewähren.
• Ein GitHub-Repository zu mehreren Azure-DevOps-Organisationen verbinden. Microsoft rät davon ab: Es kann zu unerwarteten Verknüpfungen mit AB# kommen.

Was Sie jetzt können

Sie ordnen die Dienste von GitHub und Azure DevOps einander zu und kennen die Ordnung beider Welten: Konto und Organisation, Repository und Projekt. Sie übersetzen Begriffe wie Agent und Runner, dependsOn und needs, task und uses. Sie kennen die vier Kombinationen beider Werkzeuge und die Integrationen zwischen Azure Boards, Azure Pipelines und GitHub, auch die Grenzen bei GitHub Enterprise Server. Und Sie begründen die Auswahl einer Lösung zur Automatisierung der Bereitstellung mit Microsofts Empfehlung: GitHub Actions, wenn die Repositories bei GitHub liegen, Azure Pipelines für komplexe Szenarien und zentrale Vorlagen.

Weiterlesen

• 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