Anpassen Ihrer Pipeline
Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019
Dies ist eine schrittweise Anleitung zum Anpassen Ihrer Pipeline.
Voraussetzung
Folgen Sie den Anweisungen in der Ersten Pipeline erstellen, um eine Arbeitspipeline zu erstellen.
Grundlegendes zur azure-pipelines.yml
Datei
Eine Pipeline wird mithilfe einer YAML-Datei in Ihrem Repository definiert. In der Regel wird diese Datei benannt azure-pipelines.yml
und befindet sich im Stammverzeichnis Ihres Repositorys.
Navigieren Sie zur Seite "Pipelines " in Azure Pipelines, wählen Sie die von Ihnen erstellte Pipeline aus, und wählen Sie " Bearbeiten" im Kontextmenü der Pipeline aus, um den YAML-Editor für die Pipeline zu öffnen.
Hinweis
Anweisungen zum Anzeigen und Verwalten Ihrer Pipelines im Azure DevOps-Portal finden Sie unter Navigieren in Pipelines.
Überprüfen Sie den Inhalt der YAML-Datei.
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
steps:
- task: Maven@3
inputs:
mavenPomFile: 'pom.xml'
mavenOptions: '-Xmx3072m'
javaHomeOption: 'JDKVersion'
jdkVersionOption: '1.11'
jdkArchitectureOption: 'x64'
publishJUnitResults: false
testResultsFiles: '**/surefire-reports/TEST-*.xml'
goals: 'package'
Hinweis
Der Inhalt Ihrer YAML-Datei kann je nach dem von Ihnen gestarteten Beispiel-Repo oder Upgrades in Azure Pipelines unterschiedlich sein.
Diese Pipeline wird ausgeführt, wenn Ihr Team eine Änderung an den Hauptzweig Ihres Repositorys verschiebt oder eine Pullanforderung erstellt. Sie wird auf einem von Microsoft gehosteten Linux-Computer ausgeführt. Der Pipelineprozess verfügt über einen einzelnen Schritt, der die Maven-Aufgabe ausführt.
Ändern der Plattform zum Erstellen auf
Sie können Ihr Projekt auf von Microsoft gehosteten Agents erstellen, die bereits SDKs und Tools für verschiedene Entwicklungssprachen enthalten. Oder Sie können selbst gehostete Agents mit bestimmten Tools verwenden, die Sie benötigen.
Navigieren Sie zum Editor für Ihre Pipeline, indem Sie die Bearbeitungspipelineaktion für den Build auswählen oder die Hauptseite der Pipeline bearbeiten auswählen.
Derzeit wird die Pipeline auf einem Linux-Agent ausgeführt:
pool: vmImage: "ubuntu-latest"
Um eine andere Plattform wie Windows oder Mac auszuwählen, ändern Sie den
vmImage
Wert:pool: vmImage: "windows-latest"
pool: vmImage: "macos-latest"
Wählen Sie "Speichern" aus, und bestätigen Sie dann die Änderungen, um die Ausführung Ihrer Pipeline auf einer anderen Plattform anzuzeigen.
Schritte hinzufügen
Sie können weitere Skripts oder Aufgaben als Schritte zu Ihrer Pipeline hinzufügen. Eine Aufgabe ist ein vordefiniertes Skript. Sie können Aufgaben zum Erstellen, Testen, Veröffentlichen oder Bereitstellen Ihrer App verwenden. Für Java wird die Maven-Aufgabe verwendet, die Test- und Veröffentlichungsergebnisse verarbeitet, Sie können jedoch auch eine Aufgabe verwenden, um Codeabdeckungsergebnisse zu veröffentlichen.
Öffnen Sie den YAML-Editor für Ihre Pipeline.
Fügen Sie den folgenden Codeausschnitt am Ende Der YAML-Datei hinzu.
- task: PublishCodeCoverageResults@1 inputs: codeCoverageTool: "JaCoCo" summaryFileLocation: "$(System.DefaultWorkingDirectory)/**/site/jacoco/jacoco.xml" reportDirectory: "$(System.DefaultWorkingDirectory)/**/site/jacoco" failIfCoverageEmpty: true
Wählen Sie "Speichern" aus, und bestätigen Sie dann die Änderungen.
Sie können Ihre Test- und Codeabdeckungsergebnisse anzeigen, indem Sie Ihren Build auswählen und zur Registerkarten "Test " und " Abdeckung" wechseln.
Erstellen auf mehreren Plattformen
Sie können Ihr Projekt auf mehreren Plattformen erstellen und testen. Eine Möglichkeit, dies zu tun, ist mit strategy
und matrix
. Sie können Variablen verwenden, um Daten bequem in verschiedene Teile einer Pipeline zu platzieren. In diesem Beispiel verwenden wir eine Variable, um den Namen des zu verwendenden Bilds zu übergeben.
Ersetzen Sie in Ihrer
azure-pipelines.yml
Datei diesen Inhalt:pool: vmImage: "ubuntu-latest"
mit dem folgenden Inhalt:
strategy: matrix: linux: imageName: "ubuntu-latest" mac: imageName: "macOS-latest" windows: imageName: "windows-latest" maxParallel: 3 pool: vmImage: $(imageName)
Wählen Sie "Speichern" aus, und bestätigen Sie dann die Änderungen, um die Ausführung Ihres Builds auf bis zu drei Aufträgen auf drei verschiedenen Plattformen anzuzeigen.
Jeder Agent kann jeweils nur einen Auftrag ausführen. Um mehrere Aufträge parallel auszuführen, müssen Sie mehrere Agents konfigurieren. Sie benötigen auch ausreichende parallele Aufträge.
Erstellen mit mehreren Versionen
Um ein Projekt mit unterschiedlichen Versionen dieser Sprache zu erstellen, können Sie eine matrix
Version und eine Variable verwenden. In diesem Schritt können Sie entweder das Java-Projekt mit zwei verschiedenen Versionen von Java auf einer einzigen Plattform erstellen oder verschiedene Versionen von Java auf verschiedenen Plattformen ausführen.
Hinweis
Sie können in einem Kontext nicht mehrmals verwenden strategy
.
Wenn Sie auf einer einzelnen Plattform und mehreren Versionen aufbauen möchten, fügen Sie die folgende Matrix ihrer
azure-pipelines.yml
Datei vor der Maven-Aufgabe und nach dervmImage
Datei hinzu.strategy: matrix: jdk10: jdkVersion: "1.10" jdk11: jdkVersion: "1.11" maxParallel: 2
Ersetzen Sie dann diese Zeile in Ihrer maven-Aufgabe:
jdkVersionOption: "1.11"
Durch diese Zeile:
jdkVersionOption: $(jdkVersion)
Stellen Sie sicher, dass Sie die
$(imageName)
Variable wieder auf die Plattform Ihrer Wahl ändern.Wenn Sie auf mehreren Plattformen und Versionen erstellen möchten, ersetzen Sie den gesamten Inhalt in Ihrer
azure-pipelines.yml
Datei vor der Veröffentlichungsaufgabe durch den folgenden Codeausschnitt:trigger: - main strategy: matrix: jdk10_linux: imageName: "ubuntu-latest" jdkVersion: "1.10" jdk11_windows: imageName: "windows-latest" jdkVersion: "1.11" maxParallel: 2 pool: vmImage: $(imageName) steps: - task: Maven@3 inputs: mavenPomFile: "pom.xml" mavenOptions: "-Xmx3072m" javaHomeOption: "JDKVersion" jdkVersionOption: $(jdkVersion) jdkArchitectureOption: "x64" publishJUnitResults: true testResultsFiles: "**/TEST-*.xml" goals: "package"
Wählen Sie "Speichern" aus, und bestätigen Sie dann die Änderungen, um die Ausführung von zwei Aufträgen auf zwei verschiedenen Plattformen und SDKs anzuzeigen.
Anpassen von CI-Triggern
Pipelinetrigger führen dazu, dass eine Pipeline ausgeführt wird. Sie können dazu führen trigger:
, dass eine Pipeline ausgeführt wird, wenn Sie eine Aktualisierung an eine Verzweigung verschieben. YAML-Pipelines sind standardmäßig mit einem CI-Trigger in Ihrer Standardverzweigung (normalerweise) main
konfiguriert. Sie können Trigger für bestimmte Verzweigungen oder für die Überprüfung der Pullanforderung einrichten. Ersetzen Sie für einen Pull-Anforderungsüberprüfungsauslöser einfach den trigger:
Schritt pr:
wie in den beiden folgenden Beispielen dargestellt. Standardmäßig wird die Pipeline für jede Pullanforderungsänderung ausgeführt.
Wenn Sie Trigger einrichten möchten, fügen Sie am Anfang der
azure-pipelines.yml
Datei einen der folgenden Codeausschnitte hinzu.trigger: - main - releases/*
pr: - main - releases/*
Sie können den vollständigen Namen der Verzweigung (z. B
main
. ) oder einen präfixabgleichenden Wildcard (zreleases/*
. B. ) angeben.
Pipelineeinstellungen
Es gibt einige Pipelineeinstellungen, die Sie in Ihrer YAML-Datei nicht verwalten, z. B. den YAML-Dateipfad und den aktivierten Status Ihrer Pipeline. Um diese Einstellungen zu konfigurieren, navigieren Sie zur Seite "Pipelinedetails" , und wählen Sie "Weitere Aktionen", "Einstellungen" aus. Weitere Informationen zum Navigieren und Durchsuchen Ihrer Pipelines finden Sie unter Navigationspipelinen.
Im Bereich "Pipelineeinstellungen " können Sie die folgenden Einstellungen konfigurieren.
Verarbeitung neuer Ausführungsanforderungen – Manchmal möchten Sie verhindern, dass neue Ausführungen in Ihrer Pipeline gestartet werden.
- Standardmäßig ist die Verarbeitung neuer Ausführungsanforderungen aktiviert. Diese Einstellung ermöglicht die Standardverarbeitung aller Triggertypen, einschließlich manueller Ausführung.
- Angehaltene Pipelines ermöglichen die Verarbeitung von Ausführungsanforderungen, aber diese Anforderungen werden ohne tatsächlichen Start in die Warteschlange gestellt. Wenn neue Anforderungsverarbeitung aktiviert ist, führen Sie die Verarbeitungsläufe ab der ersten Anforderung in der Warteschlange aus.
- Deaktivierte Pipelines verhindern, dass Benutzer neue Ausführung starten. Alle Trigger werden auch deaktiviert, während diese Einstellung angewendet wird.
YAML-Dateipfad – Wenn Sie ihre Pipeline jemals zur Verwendung einer anderen YAML-Datei leiten müssen, können Sie den Pfad zu dieser Datei angeben. Diese Einstellung kann auch hilfreich sein, wenn Sie Ihre YAML-Datei verschieben/umbenennen müssen.
In dieser Ausführung enthaltene Arbeitselemente automatisch verknüpfen – Die Änderungen, die einer bestimmten Pipelineausführung zugeordnet sind, haben möglicherweise Arbeitselemente zugeordnet. Wählen Sie diese Option aus, um diese Arbeitselemente mit der Ausführung zu verknüpfen. Wenn in dieser Ausführung enthaltene Arbeitselemente automatisch verknüpft werden, müssen Sie entweder eine bestimmte Verzweigung oder
*
für alle Verzweigungen angeben, die die Standardeinstellung sind. Wenn Sie eine Verzweigung angeben, sind Arbeitselemente nur mit Läufen dieser Verzweigung verknüpft. Wenn Sie angeben*
, werden Arbeitselemente für alle Ausführungen zugeordnet.- Informationen zum Abrufen von Benachrichtigungen, wenn Ihre Ausführung fehlschlägt, finden Sie unter "Verwalten von Benachrichtigungen für ein Team"
Erstellen einer Arbeitsaufgabe beim Fehler
YaML-Pipelines verfügen nicht über eine Erstellungsaufgabe für Fehlereinstellung wie klassische Buildpipelinen. Klassische Buildpipelinen sind einzelne Phasen, und das Erstellen einer Arbeitsaufgabe für Fehler gilt für die gesamte Pipeline. YAML-Pipelines können mehrstufige Sein, und eine Einstellung auf Pipelineebene ist möglicherweise nicht geeignet. Zum Implementieren des Fehlers "Arbeitselement erstellen" in einer YAML-Pipeline können Sie Methoden wie z. B. den REST-API-Aufruf erstellen oder den Arbeitselement-Erstellungsbefehl von Azure DevOps CLI az boards an dem gewünschten Punkt in Ihrer Pipeline verwenden.
Im folgenden Beispiel werden zwei Aufträge ausgeführt. Der erste Auftrag stellt die Arbeit der Pipeline dar, aber wenn er fehlschlägt, wird der zweite Auftrag ausgeführt und ein Fehler im gleichen Projekt wie die Pipeline erstellt.
# When manually running the pipeline, you can select whether it
# succeeds or fails.
parameters:
- name: succeed
displayName: Succeed or fail
type: boolean
default: false
trigger:
- main
pool:
vmImage: ubuntu-latest
jobs:
- job: Work
steps:
- script: echo Hello, world!
displayName: 'Run a one-line script'
# This malformed command causes the job to fail
# Only run this command if the succeed variable is set to false
- script: git clone malformed input
condition: eq(${{ parameters.succeed }}, false)
# This job creates a work item, and only runs if the previous job failed
- job: ErrorHandler
dependsOn: Work
condition: failed()
steps:
- bash: |
az boards work-item create \
--title "Build $(build.buildNumber) failed" \
--type bug \
--org $(System.TeamFoundationCollectionUri) \
--project $(System.TeamProject)
env:
AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
displayName: 'Create work item on failure'
Hinweis
Mit Azure Boards können Sie Ihre Arbeitsaufgabenverfolgung mithilfe verschiedener Prozesse wie Agile oder Basic konfigurieren. Jeder Prozess verfügt über unterschiedliche Arbeitsaufgabentypen, und nicht jeder Arbeitsaufgabentyp ist in jedem Prozess verfügbar. Eine Liste der Arbeitsaufgabentypen, die von jedem Prozess unterstützt werden, finden Sie unter Arbeitselementtypen (WITs).
Im vorherigen Beispiel werden Runtime-Parameter verwendet, um zu konfigurieren, ob die Pipeline erfolgreich ist oder fehlschlägt. Wenn Sie die Pipeline manuell ausführen, können Sie den Wert des succeed
Parameters festlegen. Der zweite script
Schritt im ersten Auftrag der Pipeline wertet den succeed
Parameter aus und wird nur ausgeführt, wenn succeed
auf "false" festgelegt ist.
Der zweite Auftrag in der Pipeline verfügt über eine Abhängigkeit vom ersten Auftrag und wird nur ausgeführt, wenn der erste Auftrag fehlschlägt. Der zweite Auftrag verwendet den Befehl zum Erstellen eines Fehlers mithilfe des Azure DevOps CLI-Arbeitsboards . Weitere Informationen zum Ausführen von Azure DevOps CLI-Befehlen aus einer Pipeline finden Sie unter Ausführen von Befehlen in einer YAML-Pipeline.
In diesem Beispiel werden zwei Aufträge verwendet, aber dieser ansatz kann in mehreren Phasen verwendet werden.
Hinweis
Sie können auch eine Marketplace-Erweiterung wie Create Bug on Release-Fehler verwenden, die Unterstützung für YAML-Mehrstufige Pipelines hat.
Nächste Schritte
Sie haben die Grundlagen der Anpassung Ihrer Pipeline gelernt. Als Nächstes wird empfohlen, weitere Informationen zum Anpassen einer Pipeline für die von Ihnen verwendete Sprache zu erhalten:
Oder um Ihre CI-Pipeline auf eine CI/CD-Pipeline zu erweitern, fügen Sie einen Bereitstellungsauftrag mit Schritten zum Bereitstellen Ihrer App in eine Umgebung ein.
Weitere Informationen zu den Themen in diesem Leitfaden finden Sie unter "Aufträge", "Aufgaben", " Aufgabenkatalog", " Variablen", " Trigger" oder " Problembehandlung".
Informationen zu weiteren Möglichkeiten in YAML-Pipelines finden Sie in der YAML-Schemareferenz.