Anpassen Ihrer Pipeline

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Dieser Artikel ist eine schrittweise Anleitung zur allgemeinen Anpassung Ihrer Pipeline.

Voraussetzungen

Befolgen Sie die Anweisungen zum Erstellen Ihrer ersten Pipeline, um eine funktionierende Pipeline zu erstellen.

Grundlegendes zur azure-pipelines.yml-Datei

Eine Pipeline wird mithilfe einer YAML-Datei in Ihrem Repository definiert. Normalerweise trägt diese Datei den Namen azure-pipelines.yml und befindet sich im Stammverzeichnis Ihres Repositorys.

Wechseln Sie in Azure Pipelines zur Seite Pipelines, wählen Sie die von Ihnen erstellte Pipeline aus, und wählen Sie Edit im Kontextmenü der Pipeline aus, um den YAML-Editor zu öffnen.

Untersuchen Sie den Inhalt der YAML-Datei.

 trigger:
 - main

 pool:
   vmImage: 'ubuntu-latest'

 steps:
 - task: Maven@4
   inputs:
     mavenPomFile: 'pom.xml'
     mavenOptions: '-Xmx3072m'
     javaHomeOption: 'JDKVersion'
     jdkVersionOption: '1.11'
     jdkArchitectureOption: 'x64'
     publishJUnitResults: false
     testResultsFiles: '**/surefire-reports/TEST-*.xml'
     goals: 'package'

Die Pipeline wird ausgeführt, wenn Ihr Team eine Änderung an die Hauptverzweigung des Repositorys überträgt oder eine Pullanforderung erstellt. Sie wird auf einem von Microsoft gehosteten Linux-Computer ausgeführt. Der Pipelineprozess besteht aus einem einzelnen Schritt: der Ausführung der Maven-Aufgabe.

Plattform zum Bauen ändern

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 selbstgehostete Agents mit bestimmten Tools verwenden, die Sie benötigen.

• Navigieren Sie zum Editor für Ihre Pipeline, indem Sie im Build die Pipeline bearbeiten-Aktion auswählen oder auf der Hauptseite der Pipeline Bearbeiten auswählen.

• Derzeit wird die Pipeline auf einem Linux-Agent ausgeführt:

  pool:
    vmImage: "ubuntu-latest"
  

• Um zu einer anderen Plattform wie Windows oder Mac zu wechseln, ändern Sie den Wert vmImage:

  pool:
    vmImage: "windows-latest"
  

  pool:
    vmImage: "macos-latest"
  

• Wählen Sie Speichern aus und bestätigen Sie dann die Änderungen, damit Ihre Pipeline auf einer anderen Plattform ausgeführt wird.

Schritte hinzufügen

Sie können Ihrer Pipeline weitere Skripts oder Aufgaben als Schritte hinzufügen. Eine Aufgabe ist ein vorgefertigtes Skript. Sie können Aufgaben zum Erstellen, Testen, Veröffentlichen oder Bereitstellen Ihrer App verwenden. Für Java haben wir den Maven-Task verwendet, der Testergebnisse und Veröffentlichungen behandelt. Sie können jedoch auch einen Task verwenden, um Codeabdeckungsergebnisse zu veröffentlichen.

• Öffnen Sie den YAML-Editor für Ihre Pipeline.

• Fügen Sie den folgenden Codeschnipsel am Ende Ihrer YAML-Datei hinzu.

  - task: PublishCodeCoverageResults@2
    inputs:
      summaryFileLocation: "$(System.DefaultWorkingDirectory)/**/site/jacoco/jacoco.xml" # Path to summary files
      reportDirectory: "$(System.DefaultWorkingDirectory)/**/site/jacoco" # Path to report directory
      failIfCoverageEmpty: true # Fail if code coverage results are missing
  

• Wählen Sie Speichern aus und bestätigen Sie dann die Änderungen.

• Sie können Ihre Test- und Code Coverage-Ergebnisse anzeigen, indem Sie Ihren Build auswählen und zu den Registerkarten Test und Coverage wechseln.

Entwickeln über mehrere Plattformen hinweg

Sie können Ihr Projekt auf mehreren Plattformen erstellen und testen. strategy und matrix sind eine Möglichkeit dazu. Sie können Variablen verwenden, um Daten bequem in verschiedene Teile einer Pipeline einzufügen. In diesem Beispiel verwenden wir eine Variable, um den Namen des Image zu übergeben, das wir verwenden möchten.

• Ersetzen Sie in Ihrer azure-pipelines.yml-Datei den folgenden Inhalt:

  pool:
    vmImage: "ubuntu-latest"
  

  mit folgendem 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, damit Ihr Build bis zu drei Aufträge auf drei verschiedenen Plattformen ausführen kann.

Jeder Agent kann jeweils nur einen Auftrag ausführen. Um mehrere Aufträge parallel auszuführen, müssen Sie mehrere Agents konfigurieren. Außerdem müssen genügend Parallelaufträge vorhanden sein.

Kompilieren mit mehreren Versionen

Um ein Projekt mit verschiedenen Versionen dieser Sprache zu erstellen, können Sie eine matrix der Versionen und eine Variable verwenden. In diesem Schritt können Sie entweder das Java Projekt mit zwei verschiedenen Versionen von Java auf einer einzelnen Plattform erstellen oder verschiedene Versionen von Java auf verschiedenen Plattformen ausführen.

• Wenn Sie auf einer einzelnen Plattform und mehreren Versionen erstellen möchten, fügen Sie der azure-pipelines.yml-Datei vor der Maven-Aufgabe und nach der vmImage die folgende Matrix 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"
  

  Mit dieser 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 Codeschnipsel:

  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@4
    inputs:
      mavenPomFile: "pom.xml"
      mavenOptions: "-Xmx3072m"
      javaHomeOption: "JDKVersion"
      jdkVersionOption: $(jdkVersion)
      jdkArchitectureOption: "x64"
      publishJUnitResults: true
      testResultsFiles: "**/TEST-*.xml"
      goals: "package"
  

• Wählen Sie Speichern und bestätigen Sie dann die Änderungen, damit Ihr Build zwei Aufträge auf zwei verschiedenen Plattformen und SDKs ausführen kann.

CI-Trigger anpassen

Pipeline-Trigger verursachen, dass eine Pipeline ausgeführt wird. Sie können trigger: verwenden, um die Ausführung einer Pipeline zu veranlassen, wenn Sie ein Update per Push an einen Branch übertragen. YAML-Pipelines werden standardmäßig mit einem CI-Trigger auf Ihrem Standardbranch konfiguriert (in der Regel main). Sie können Trigger für bestimmte Branches oder für die Pull Request-Validierung einrichten. Ersetzen Sie für einen Pull Request-Validierungstrigger einfach den trigger:-Schritt durch pr:, wie in den beiden folgenden Beispielen gezeigt. Standardmäßig wird die Pipeline für jede Pull Request-Änderung ausgeführt.

• Wenn Sie Trigger einrichten möchten, fügen Sie am Anfang der azure-pipelines.yml-Datei einen der folgenden Codeschnipsel hinzu.

  trigger:
    - main
    - releases/*
  

  pr:
    - main
    - releases/*
  

  Sie können den vollständigen Namen des Branchs (z. B. main) oder eine Wildcard mit übereinstimmendem Präfix (z. B. releases/*) angeben.

Pipelineeinstellungen

Sie können Pipelineeinstellungen über das Menü Weitere Aktionen auf der Seite mit den Pipelinedetails anzeigen und konfigurieren.

• Verwalten der Sicherheit - Verwalten der Sicherheit
• Umbenennen/Verschieben: Bearbeiten Sie den Pipelinenamen und den Ordnerspeicherort.
• Status-Badge - Fügen Sie Ihrem Repository ein Status-Badge hinzu
• Löschen - Löscht die Pipeline, einschließlich aller Builds und zugehöriger Artefakte.
• Geplante Ausführungen - Ansicht „Geplante Ausführungen“

Wählen Sie Einstellungen aus, um die folgenden Pipelineeinstellungen zu konfigurieren.

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ührungen.
  • Angehaltene Pipelines ermöglichen die Verarbeitung von Ausführungsanforderungen, diese Anforderungen werden jedoch in die Warteschlange gestellt, ohne tatsächlich gestartet zu werden. Wenn die Verarbeitung neuer Anforderungen aktiviert ist, wird die Verarbeitung ab der ersten Anforderung in der Warteschlange fortgesetzt.
  • Deaktivierte Pipelines verhindern, dass Benutzer neue Ausführungen starten. Es sind auch alle Trigger deaktiviert, solange diese Einstellung angewendet ist. Bei allen Build-Richtlinien, die eine deaktivierte Pipeline verwenden, wird im PR-Übersichtsfenster neben der Build-Richtlinie die Nachricht „Build kann nicht in die Warteschleife gestellt werden“ angezeigt, und der Status der Build-Richtlinie wird als "Fehlgeschlagen" angezeigt.

• YAML-Dateipfad: Wenn Sie Ihre Pipeline jemals anweisen müssen, eine andere YAML-Datei zu verwenden, können Sie den Pfad zu dieser Datei angeben. Diese Einstellung kann auch nützlich sein, wenn Sie Ihre YAML-Datei verschieben/umbenennen müssen.

• In dieser Ausführung enthaltene Arbeitsitems automatisch verknüpfen – Die Änderungen, die einer bestimmten Pipelineausführung zugeordnet sind, könnten mit Arbeitsitems verbunden sein. 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üpfen ausgewählt ist, müssen Sie entweder einen bestimmten Branch oder * für alle Branches (die Standardeinstellung) angeben. Wenn Sie einen Branch angeben, werden Arbeitselemente nur mit Ausführungen dieses Branches in Verbindung gebracht. Wenn Sie * angeben, werden Arbeitselemente für alle Ausführungen zugeordnet.

  

  • Um Benachrichtigungen zu erhalten, wenn Ausführungen fehlschlagen, erfahren Sie, wie Sie Benachrichtigungen für ein Team verwalten.

Sicherheit verwalten

Sie können die Pipelinesicherheit auf Projektebene über Weitere Aktionen auf der Zielseite der Pipelines und auf Pipelineebene auf der Seite mit den Pipelinedetails konfigurieren.

Zur Unterstützung der Sicherheit Ihrer Pipelinevorgänge können Sie Benutzer einer integrierten Sicherheitsgruppe hinzufügen, individuelle Berechtigungen für einen Benutzer oder eine Gruppe festlegen oder Benutzer vordefinierten Rollen hinzufügen. Sie können die Sicherheit für Azure Pipelines im Webportal verwalten, entweder über den Benutzer- oder Administratorkontext. Weitere Informationen zum Konfigurieren der Sicherheit von Pipelines finden Sie unter Pipelineberechtigungen und Sicherheitsrollen.

Erstellen eines Arbeitselements bei Fehlern

# 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'

# 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: |
      curl \
        -X POST \
        -H 'Authorization: Basic $(System.AccessToken)' \
        -H 'Content-Type: application/json-patch+json' \
        -d '[
              {
                "op": "add",
                "path": "/fields/System.Title",
                "from": null,
                "value": "git clone failed"
              }
            ]' \
        "$(System.CollectionUri)$(System.TeamProject)/_apis//wit/workitems/$Bug?api-version=7.1-preview.3
"
    env:
        SYSTEM_ACCESSTOKEN: $(System.AccessToken)
    displayName: 'Create work item on failure'

In diesem Beispiel werden zwei Aufträge verwendet, aber dieser Ansatz kann über mehrere Phasen hinweg verwendet werden.

Verwenden von KI zum Anpassen Ihrer Pipeline

Wenn Sie den Azure DevOps MCP Server konfigurieren, erhalten Sie intelligente Empfehlungen zum Optimieren und Anpassen Ihrer Pipeline mithilfe natürlicher Sprache.

Nächste Schritte

Sie haben nun die Grundlagen zur Anpassung Ihrer Pipeline kennengelernt. Als Nächstes sollten Sie mehr über das Anpassen einer Pipeline für die von Ihnen verwendete Sprache erfahren:

• .NET Core
• Behälter
• Los geht's
• Java
• Node.js
• Python

Damit Sie Ihre CI-Pipeline in eine CI/CD-Pipeline erweitern können, fügen Sie einen Bereitstellungsauftrag mit Schritten zum Bereitstellen Ihrer App in einer Umgebung hinzu.

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.