Eine CI-Pipeline mit Azure Pipelines erstellen

Continuous Integration (CI) bezeichnet die Praxis, Codeänderungen häufig in einen gemeinsamen Branch zu integrieren, wobei jede Zusammenführung automatisch einen Build und einen Testlauf auslöst. Ziel ist es, Integrationsfehler frühzeitig zu erkennen, bevor daraus große und schwer behebbare Probleme entstehen. Eine gute CI-Pipeline erstellt den Build, führt Komponententests aus, misst die Codeabdeckung, führt eine statische Analyse durch und erzeugt innerhalb weniger Minuten ein bereitstellbares Artefakt. Azure Pipelines stellt die Automatisierungsengine für diese Praxis bereit.

CI-Pipelines von Azure Pipelines werden in einer Datei azure-pipelines.yml im Stammverzeichnis Ihres Repositorys definiert. Die YAML-Datei legt Trigger (wann die Pipeline ausgeführt wird), einen Pool (welcher Agenttyp verwendet wird) sowie eine Hierarchie aus Stages, Jobs und Steps fest. Stages werden standardmäßig nacheinander ausgeführt. Jobs innerhalb einer Stage werden standardmäßig parallel ausgeführt. Steps innerhalb eines Jobs werden nacheinander ausgeführt. Diese Struktur ermöglicht eine sehr genaue Steuerung des Ausführungsablaufs der Pipeline.

Azure Pipelines unterstützt mehrere Triggertypen. Branch-Trigger führen die Pipeline aus, wenn Code in angegebene Branches gepusht wird. Pull-Request-Trigger (PR-Trigger) werden ausgelöst, wenn ein PR für Zielbranches geöffnet oder aktualisiert wird – das ist entscheidend, um Code vor dem Zusammenführen zu überprüfen. Geplante Trigger werden zu einer festgelegten Zeit ausgeführt (z. B. für nächtliche Builds). Pipeline-Trigger verketten Pipelines miteinander. Geben Sie trigger: none an, um automatische Ausführungen zu deaktivieren und nur die manuelle Ausführung zuzulassen.

Pipeline-Steps sind entweder Skripts (Bash- oder PowerShell-Befehle) oder Tasks (vorgefertigte, parametrisierte Einheiten aus dem Azure-DevOps-Marketplace). Tasks wie NodeTool@0, DotNetCoreCLI@2 und Maven@3 kapseln gängige Buildvorgänge. Verwenden Sie für jeden Step displayName, damit die Pipelineprotokolle gut lesbar sind. Jeder Step wird der Reihe nach ausgeführt, und die Pipeline schlägt fehl, wenn ein Step mit einem Code ungleich null beendet wird, sofern Sie nicht continueOnError: true festlegen.

Veröffentlichen Sie die Ergebnisse nach der Testausführung mit dem Task PublishTestResults in Azure DevOps. Azure Pipelines analysiert JUnit-, NUnit-, XUnit- oder VSTest-Ergebnisdateien und zeigt in der Benutzeroberfläche des Pipelineausführung die Anzahl bestandener und fehlgeschlagener Tests, die Dauer des Testlaufs sowie Details zu einzelnen Tests an. Der Testverlauf wird über die Zeit erfasst, sodass Sie instabile Tests und Regressionen erkennen können. Das ist entscheidend für die teamweite Transparenz der Codequalität.

Veröffentlichen Sie Berichte zur Codeabdeckung, damit Azure Pipelines Prozentsätze und Trends der Abdeckung in der Pipelinebenutzeroberfläche anzeigt. Der Task PublishCodeCoverageResults akzeptiert Berichte im Cobertura- oder JaCoCo-Format. Kombinieren Sie dies mit Gates für die Branch-Abdeckung: Konfigurieren Sie einen Mindestschwellenwert und lassen Sie den Build fehlschlagen, wenn die Abdeckung darunter fällt. Trends der Abdeckung helfen dabei zu erkennen, wenn neuer Code ohne entsprechende Tests hinzugefügt wird.

Speichern Sie die Pipelinekonfiguration in Variablen, die in YAML auf Pipeline-, Stage- oder Jobebene definiert werden. Verwenden Sie für vertrauliche Werte (API-Schlüssel, Kennwörter) geheime Variablen – legen Sie diese in der Pipelinesammlung (Benutzeroberfläche) oder in Variablengruppen fest und verweisen Sie in YAML darauf. Variablengruppen sind wiederverwendbare Sammlungen von Variablen, die von mehreren Pipelines gemeinsam verwendet werden. Verknüpfen Sie eine Variablengruppe mit Azure Key Vault, um Geheimnisse aus Key Vault automatisch mit Pipelinevariablen zu synchronisieren.

Paketieren Sie die Ausgabe nach einem erfolgreichen Build als Pipelineartefakt, damit nachgelagerte Stages (z. B. für die Bereitstellung) darauf zugreifen können. Verwenden Sie PublishPipelineArtifact, um Dateien vom Build-Agent in den Azure-DevOps-Artefaktspeicher hochzuladen. Verwenden Sie in einer späteren Stage oder einem späteren Job DownloadPipelineArtifact, um das Artefakt abzurufen. Dadurch wird der Buildjob von den Bereitstellungsjobs entkoppelt, die auf anderen Agents oder in anderen Stages ausgeführt werden können.

Führen Sie unabhängige Aufgaben parallel aus, indem Sie mehrere Jobs innerhalb einer Stage definieren. Führen Sie beispielsweise Komponententests und Sicherheitsscans gleichzeitig statt nacheinander aus. Parallele Jobs benötigen separate Buildminuten, können die Gesamtdauer der Pipeline jedoch deutlich verkürzen. Verwenden Sie die Eigenschaft dependsOn, damit ein Job vor dem Start auf den Abschluss eines oder mehrerer anderer Jobs wartet. So erstellen Sie innerhalb einer Stage einen Abhängigkeitsgraphen.

Verknüpfen Sie Ihre CI-Pipeline mit einer Branchrichtlinie in Azure Repos, damit sie bei Pull Requests für main automatisch als Buildvalidierungsprüfung ausgeführt wird. Das Zusammenführen ist blockiert, bis die Pipeline erfolgreich abgeschlossen wurde. Kombinieren Sie mehrere Prüfungen: Die CI-Pipeline muss erfolgreich sein, mindestens zwei Reviewer müssen genehmigen, alle Kommentare müssen aufgelöst sein, und ein verknüpftes Arbeitselement muss vorhanden sein. Dadurch entsteht ein Qualitätstor, das verhindert, dass fehlerhafter Code in den Main-Branch übernommen wird.

Überprüfen Sie die Ergebnisse nach Abschluss einer Pipelineausführung im Azure-DevOps-Portal. Die Registerkarte Summary zeigt den Gesamtstatus und die Dauer an. Die Registerkarte Tests listet alle Testergebnisse auf und ermöglicht das Filtern nach Ergebnis. Die Registerkarte Code Coverage zeigt den Abdeckungsprozentsatz und hebt nicht abgedeckte Zeilen hervor. Klicken Sie auf einen beliebigen Job, um die schrittweise Protokollausgabe anzuzeigen. Bei fehlgeschlagenen Pipelines wird der fehlerhafte Step rot hervorgehoben und die vollständige Fehlerausgabe zur schnellen Diagnose angezeigt.

Überprüfen Sie Ihr Verständnis der Konzepte aus Microsoft Azure Fundamentals (AZ-900), die in dieser Lektion behandelt wurden.

In dieser Lektion haben Sie gelernt: Azure-Pipelines-YAML definiert CI-Pipelines mit Stages, Jobs und Steps für Build, Tests und die Erstellung von Artefakten. PR-Trigger und Branchrichtlinien erzwingen Qualitätstore, die das Zusammenführen fehlerhaften Codes blockieren, und die Tasks PublishTestResults und PublishCodeCoverageResults machen die Testqualität im gesamten Team sichtbar. Als Nächstes sehen wir uns Continuous Deployment für Azure an.