In Teil 1 wurde der azure-pipelines.yml über einen Pull Request in den Zweig main eingebunden. In diesem zweiten Teil hängen wir diese YAML an eine Pipeline an und führen sie auf einem von Microsoft gehosteten Windows-Agenten in der Cloud aus.

Der Abschnitt „Pipelines“.

Der Abschnitt „Pipelines“ in der Seitenleiste enthält mehr Elemente als Repos:

  • Pipelines – die CI-Pipelines (Build)
  • Umgebungen – Bereitstellungsziele wie Akzeptanz und Produktion
  • Releases – die klassischen visuellen Release-Pipelines (älteres System, wird durch mehrstufiges YAML ersetzt)
  • Bibliothek – Variablengruppen und sichere Dateien
  • Aufgabengruppen – wiederverwendbare Aufgabenblöcke, die über mehrere Pipelines hinweg gemeinsam genutzt werden können
  • Bereitstellungsgruppen – selbstgehostete Agenten, gruppiert nach Umgebung

Bei einem neuen Projekt ist die Pipelines-Liste leer.

Seite „Pipelines leeren“ mit der Schaltfläche „Pipeline erstellen“.

Eine Pipeline erstellen: der Assistent

Über Pipeline erstellen startet der vierstufige Assistent: Verbinden → Auswählen → Konfigurieren → Überprüfen.

Schritt 1 – Verbinden: Wo ist der Code? ADO unterstützt Azure Repos Git, GitHub, Bitbucket Cloud, andere Git-Server und Subversion. Unten gibt es auch einen Link zum klassischen Editor – dem alten visuellen Pipeline-Builder ohne YAML. Dies wird nicht mehr aktiv weiterentwickelt.

Schritt 1 des Pipeline-Assistenten: Quellenauswahl

Schritt 2 – Wählen Sie: welches Repository? Da es im Projekt nur ein Repo gibt, ist dev-ops-lab01 die einzige Option.

Schritt 2 des Pipeline-Assistenten: Auswahl eines Repositorys

Schritt 3 – Konfigurieren wird automatisch übersprungen. ADO erkennt, dass im Stammverzeichnis des Repos bereits ein azure-pipelines.yml vorhanden ist, und springt direkt zur Überprüfung.

Schritt 4 – Überprüfung: Das vorhandene YAML wird angezeigt. ADO liest die Datei direkt aus dem Repo – es wird nichts kopiert oder separat gespeichert. Die Pipeline ist die YAML im Repo.

Schritt 4 des Pipeline-Assistenten: YAML-Überprüfung mit vorhandenem Code

Das in Teil 1 erstellte YAML:

 1trigger:
 2  - main
 3
 4pool:
 5  vmImage: 'windows-latest'
 6
 7steps:
 8  - task: PowerShell@2
 9    displayName: 'System information'
10    inputs:
11      targetType: 'inline'
12      script: |
13        Write-Host "Hostname: $env:COMPUTERNAME"
14        Write-Host "OS: $env:OS"
15        Write-Host "Build number: $(Build.BuildNumber)"
16        Write-Host "Branch: $(Build.SourceBranchName)"

Die Schlüsselkomponenten:

SchlüsselwortBedeutung
triggerEin Push auf main startet die Pipeline automatisch
pool.vmImageVon Microsoft gehosteter Agent – ​​windows-latest ist das neueste Windows Server-Image
stepsDie Liste der auszuführenden Schritte
task: PowerShell@2Eine integrierte ADO-Aufgabe, Version 2
$(Build.BuildNumber)Integrierte ADO-Variable, automatisch gefüllt
$(Build.SourceBranchName)Integrierte ADO-Variable mit dem Filialnamen

Über Run wird die Pipeline zum ersten Mal gestartet.

Der erste Lauf

Nach dem Start zeigt ADO die Laufzusammenfassung an. Die Pipeline wurde erfolgreich abgeschlossen.

Zusammenfassung des Laufs: Etappe in 15 Sekunden abgeschlossen

Was ist sichtbar:

  • #20260414.1 – Build-Nummer, erstellt aus Datum und Sequenznummer – Zusammengeführter PR 1: azure-pipelines.yml hinzugefügt – der Commit, gegen den dies ausgeführt wurde
  • Zweig main, Commit aaedef9f – der genaue Merge-Commit aus dem PR in Teil 1
  • Phase: 1 Auftrag in 15 Sekunden abgeschlossen – Gesamtausführungszeit einschließlich Agentenbereitstellung

Das Jobprotokoll

Durch Klicken auf Auftrag wird die detaillierte Protokollansicht geöffnet. Die linke Seitenleiste zeigt alle Schritte, die ADO rund um die benutzerdefinierten YAML-Schritte automatisch ausführt:

  • Job initialisieren – Agent ist konfiguriert
  • Checkout dev-ops-lab01@main – das Repo wird auf dem Agenten geklont
  • Systeminformationen – die benutzerdefinierte PowerShell-Aufgabe
  • Nach dem Auftrag: Auschecken – Aufräumen nach dem Auschecken
  • Auftrag abschließen – Agent meldet sich ab
  • Build-Status melden – Der Status wird an das Repo zurückgemeldet

Auftragsprotokoll mit allen Schritten und Zeitangaben

Das Hauptprotokoll zeigt die Agenten-Metadaten: Pool: Azure Pipelines, Image: windows-latest, Agent: Azure Pipelines 1. Hierbei handelt es sich um eine Einweg-VM in einem Microsoft-Rechenzentrum, die bei Bedarf für diesen Auftrag bereitgestellt und nach Abschluss zerstört wurde.

PowerShell-Ausgabe

Die Ausgabe des Systeminformationsschritts:

PowerShell-Aufgabenausgabe mit Hostname und Variablen

1Hostname: runnervm67wqg
2OS: Windows_NT
3Build number: 20260414.1
4Branch: main

Der Agent heißt runnervm67wqg – eine zufällig zugewiesene, von Microsoft gehostete Windows-VM. Die ADO-Variablen $(Build.BuildNumber) und $(Build.SourceBranchName) wurden von der Plattform automatisch mit den richtigen Werten gefüllt.

Was wurde erreicht

Nach diesem zweiten Teil ist klar, wie eine YAML-Pipeline in Azure DevOps funktioniert:

– Der Pipeline-Assistent verknüpft eine YAML-Datei im Repository mit einer Pipeline-Definition

  • ADO erkennt automatisch ein vorhandenes azure-pipelines.yml – Ein von Microsoft gehosteter Agent wird bei Bedarf bereitgestellt, führt den Auftrag aus und wird anschließend verworfen
  • Integrierte ADO-Variablen sind in jedem Schritt ohne Konfiguration verfügbar
  • Das Jobprotokoll zeigt alle Schritte, einschließlich der von ADO selbst hinzugefügten automatischen Schritte

In Teil 3 erweitern wir die Pipeline um Stufen und Jobs – die Bausteine für echte CI/CD-Pipelines mit mehreren Umgebungen.