Pipelineausführungssequenz

  • Artikel
  • 13 Minuten Lesedauer

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

Ausführungen stellen eine Ausführung einer Pipeline dar. Während einer Ausführung wird die Pipeline verarbeitet, und Agents verarbeiten einen oder mehrere Aufträge. Eine Pipelineausführung umfasst Aufträge, Schritte und Aufgaben. Führt sowohl Continuous Integration (CI) als auch CD-Pipelines (Continuous Integration) mit Strom aus.

Pipelineübersicht

Wenn Sie eine Pipeline ausführen, passieren viele Dinge im Hintergrund. Obwohl Sie oft nichts über sie wissen müssen, ist es manchmal nützlich, das große Ganze zu haben. Auf allgemeiner Ebene führt Azure Pipelines Folgendes aus:

Auf der Agentseite führt ein Agent für jeden Auftrag Folgendes aus:

Aufträge können erfolgreich sein, fehlschlagen oder abgebrochen werden. Es gibt auch Situationen, in denen ein Auftrag möglicherweise nicht abgeschlossen ist. Wenn Sie wissen, wie dies geschieht, können Sie Probleme beheben.

Lassen Sie uns jede Aktion einzeln aufteilen.

Verarbeiten der Pipeline

Erweitern von YAML-Vorlagen

Um eine Pipeline in eine Ausführung umzuwandeln, führt Azure Pipelines mehrere Schritte in dieser Reihenfolge durch:

  1. Erweitern Sie zunächst Vorlagen , und werten Sie Vorlagenausdrücke aus.
  2. Bewerten Sie als Nächstes Abhängigkeiten auf Phasenebene , um die erste(n) auszuführende(n) Phase(en) zu wählen.
  3. Für jede Phase, die für die Ausführung ausgewählt ist, passieren zwei Dinge:
  4. Erweitern Sie für jeden auszuführenden Auftrag mehrere Konfigurationen (strategy: matrix oder strategy: parallel in YAML) in mehrere Laufzeitaufträge.
  5. Bewerten Sie für jeden Laufzeitauftrag die Bedingungen , um zu entscheiden, ob dieser Auftrag für die Ausführung berechtigt ist.
  6. Fordern Sie einen Agent für jeden berechtigten Laufzeitauftrag an.

Nach Abschluss der Laufzeitaufträge wird von Azure Pipelines überprüft, ob neue Aufträge ausgeführt werden können. Wenn dies der Fall ist, wiederholen Sie die Schritte 4 bis 6 mit den neuen Aufträgen. Ebenso werden die Schritte 2 bis 6 nach Abschluss der Phasen für alle neuen Phasen wiederholt.

Diese Reihenfolge hilft bei der Beantwortung einer häufigen Frage: Warum kann ich bestimmte Variablen nicht in meinen Vorlagenparametern verwenden? Schritt 1 (Vorlagenerweiterung) basiert ausschließlich auf dem Text des YAML-Dokuments. Während dieses Schritts sind keine Laufzeitvariablen vorhanden. Nach Schritt 1 wurden Vorlagenparameter aufgelöst und sind nicht mehr vorhanden.

Es beantwortet auch ein weiteres häufiges Problem: Warum kann ich keine Variablen verwenden, um Dienstverbindungs-/Umgebungsnamen aufzulösen? Ressourcen werden autorisiert, bevor mit der Ausführung einer Phase begonnen werden kann. Daher sind keine Variablen auf Phasen- und Auftragsebene verfügbar. Variablen auf Pipelineebene können verwendet werden, aber nur die Variablen, die explizit in der Pipeline enthalten sind. Variablengruppen sind selbst eine Ressource, die der Autorisierung unterliegt, sodass ihre Daten bei der Überprüfung der Ressourcenautorisierung ebenfalls nicht verfügbar sind.

Anfordern eines Agents

Wenn Azure Pipelines einen Auftrag ausführen muss, wird der Pool nach einem Agent gefragt. (Serveraufträge sind eine Ausnahme, da sie auf dem Azure Pipelines-Server selbst ausgeführt werden.) Von Microsoft gehostete und selbstgehostete Agentpools funktionieren etwas anders.

Von Microsoft gehostete Agentpoolanforderungen

Zunächst überprüft der Dienst die parallelen Aufträge Ihrer Organisation. Es addiert alle ausgeführten Aufträge auf allen von Microsoft gehosteten Agents und vergleicht diese mit der Anzahl der erworbenen parallelen Aufträge. Wenn keine parallelen Slots verfügbar sind, muss der Auftrag auf einen Slot warten, um freizugeben.

Sobald ein paralleler Slot verfügbar ist, wird der Auftrag an den angeforderten Agent-Typ weitergeleitet. Konzeptionell ist der von Microsoft gehostete Pool ein riesiger globaler Pool von Computern. (In Wirklichkeit handelt es sich um viele verschiedene physische Pools, die nach Geografie und Betriebssystemtyp unterteilt sind.) Basierend auf dem vmImage (in YAML) oder Poolnamen (im klassischen Editor) angeforderten Namen wird ein Agent ausgewählt.

Poolauswahl

Alle Agents im Microsoft-Pool sind neue, neue virtuelle Computer, die noch keine Pipelines ausgeführt haben. Nach Abschluss des Auftrags wird die Agent-VM verworfen.

Selbstgehostete Agentpoolanforderungen

Ähnlich wie beim von Microsoft gehosteten Pool überprüft der Dienst zunächst die parallelen Aufträge Ihrer Organisation. Es addiert alle ausgeführten Aufträge auf allen selbstgehosteten Agents und vergleicht diese mit der Anzahl der erworbenen parallelen Aufträge. Wenn keine parallelen Slots verfügbar sind, muss der Auftrag auf einen Slot warten, um freizugeben.

Sobald ein paralleler Slot verfügbar ist, wird der selbstgehostete Pool auf einen kompatiblen Agent untersucht. Selbstgehostete Agents bieten Funktionen, bei denen es sich um Zeichenfolgen handelt, die angeben, dass eine bestimmte Software installiert ist oder Einstellungen konfiguriert sind. Die Pipeline hat Anforderungen, d. h. die Funktionen, die zum Ausführen des Auftrags erforderlich sind. Wenn ein freier Agent, dessen Funktionen den Anforderungen der Pipeline entsprechen, nicht gefunden werden kann, wartet der Auftrag weiterhin. Wenn im Pool keine Agents vorhanden sind, deren Funktionen den Anforderungen entsprechen, schlägt der Auftrag fehl.

Selbstgehostete Agents werden in der Regel von Der Ausführung bis zur Ausführung wiederverwendet. Bei selbstgehosteten Agents kann ein Pipelineauftrag Nebenwirkungen haben, z. B. das Aufwärmen von Caches oder die meisten Commits, die bereits im lokalen Repository verfügbar sind.

Vorbereiten der Ausführung eines Auftrags

Sobald ein Agent einen Auftrag angenommen hat, muss er sich vorbereiten. Der Agent lädt alle Aufgaben herunter (und speichert sie für das nächste Mal zwischen), die zum Ausführen des Auftrags erforderlich sind. Es erstellt Speicherplatz auf dem Datenträger, um den Quellcode, Artefakte und Ausgaben, die in der Ausführung verwendet werden, aufzunehmen. Anschließend werden die Schritte ausgeführt.

Ausführen der einzelnen Schritte

Die Schritte werden sequenziell nacheinander ausgeführt. Bevor ein Schritt beginnen kann, müssen alle vorherigen Schritte abgeschlossen (oder übersprungen werden).

Ausführen jeder Aufgabe

Schritte werden von Aufgaben implementiert. Aufgaben selbst werden als Node.js- oder PowerShell-Skripts implementiert. Das Aufgabensystem leitet Eingaben und Ausgaben an die unterstützenden Skripts weiter. Außerdem werden einige gängige Dienste bereitgestellt, z. B. das Ändern des Systempfads und das Erstellen neuer Pipelinevariablen.

Jeder Schritt wird in einem eigenen Prozess ausgeführt, wobei er von der Umgebung abgeschirmt wird, die von den vorherigen Schritten verlassen wurde. Aufgrund dieses Prozess-pro-Schritt-Modells werden Umgebungsvariablen zwischen den Schritten nicht beibehalten. Aufgaben und Skripts verfügen jedoch über einen Mechanismus zur Kommunikation mit dem Agent: Protokollierungsbefehle. Wenn eine Aufgabe oder ein Skript einen Protokollierungsbefehl zum Standard schreibt, führt der Agent alle erforderlichen Aktionen aus.

Es gibt einen Agent-Befehl zum Erstellen neuer Pipelinevariablen. Pipelinevariablen werden im nächsten Schritt automatisch in Umgebungsvariablen konvertiert. Um eine neue Variable myVar mit dem Wert festzulegen myValue, kann ein Skript folgendes tun:

echo '##vso[task.setVariable variable=myVar]myValue'

Write-Host "##vso[task.setVariable variable=myVar]myValue"

Berichte und Sammeln von Ergebnissen

Jeder Schritt kann Warnungen, Fehler und Fehler melden. Fehler und Warnungen werden an die Pipelinezusammenfassungsseite gemeldet, wobei die Aufgabe als "mit Problemen erfolgreich" gekennzeichnet wird. Fehler werden auch an die Zusammenfassungsseite gemeldet, markieren die Aufgabe jedoch als "fehlgeschlagen". Ein Schritt ist ein Fehler, wenn er entweder einen Fehler explizit meldet (mithilfe eines ##vso Befehls) oder das Skript mit einem Exitcode ungleich 0 beendet.

Protokoll- und Ergebnisfluss vom Agent zum Dienst

Während der Ausführung der Schritte sendet der Agent ständig Ausgabezeilen an den Dienst. Aus diesem Grund können Sie einen Livefeed der Konsole sehen. Am Ende jedes Schritts wird auch die gesamte Ausgabe des Schritts als Protokolldatei hochgeladen. Protokolle können heruntergeladen werden, sobald die Pipeline abgeschlossen ist. Weitere Elemente, die der Agent hochladen kann, sind Artefakte und Testergebnisse. Diese sind auch nach Abschluss der Pipeline verfügbar.

Zustand und Bedingungen

Der Agent verfolgt den Erfolg oder Fehler jedes Schritts nach. Wenn Schritte mit Problemen erfolgreich sind oder fehlschlagen, wird der Status des Auftrags aktualisiert. Der Auftrag spiegelt immer das "schlechteste" Ergebnis der einzelnen Schritte wider: Wenn ein Schritt fehlschlägt, schlägt der Auftrag ebenfalls fehl.

Vor dem Ausführen eines Schritts überprüft der Agent die Bedingung dieses Schritts, um zu bestimmen, ob er ausgeführt werden soll. Standardmäßig wird ein Schritt nur ausgeführt, wenn der Status des Auftrags erfolgreich oder mit Problemen erfolgreich ist. Viele Aufträge verfügen über Bereinigungsschritte, die unabhängig davon ausgeführt werden müssen, was sonst passiert ist, damit sie die Bedingung "always()" angeben können. Bereinigungsschritte können auch so festgelegt werden, dass sie nur beim Abbruch ausgeführt werden. Bei einem erfolgreichen Bereinigungsschritt kann der Auftrag nicht vor einem Fehler gespeichert werden. Aufträge können nie wieder zum Erfolg zurückkehren, nachdem ein Fehler aufgetreten ist.

Timeouts und Trennungen

Jeder Auftrag weist ein Timeout auf. Wenn der Auftrag zum angegebenen Zeitpunkt nicht abgeschlossen wurde, bricht der Server den Auftrag ab. Er versucht, dem Agent zu signalisieren, dass er beendet wird, und markiert den Auftrag als abgebrochen. AufSeiten des Agents bedeutet dies, dass alle verbleibenden Schritte abgebrochen und alle verbleibenden Ergebnisse hochgeladen werden.

Aufträge verfügen über eine Karenzzeit, die als Abbruchtimeout bezeichnet wird, in der alle Abbrucharbeiten abgeschlossen werden sollen. (Denken Sie daran, dass Schritte so markiert werden können, dass sie auch beim Abbruch ausgeführt werden.) Wenn der Agent nach dem Timeout und dem Abbruchtimeout nicht gemeldet hat, dass die Arbeit beendet wurde, markiert der Server den Auftrag als Fehler.

Da Azure Pipelines arbeit auf Agentcomputer verteilt, reagieren Agents möglicherweise von Zeit zu Zeit nicht mehr auf den Server. Dies kann passieren, wenn der Hostcomputer des Agents wegfällt (Stromausfall, VM ausgeschaltet) oder wenn ein Netzwerkfehler vorliegt. Um diese Bedingungen zu erkennen, sendet der Agent einmal pro Minute eine Heartbeat-Nachricht, um den Server darüber zu informieren, dass er noch in Betrieb ist. Wenn der Server fünf aufeinander folgende Minuten lang keinen Heartbeat empfängt, wird davon ausgegangen, dass der Agent nicht zurückkommt. Der Auftrag wird als Fehler markiert, sodass der Benutzer wissen lässt, dass er die Pipeline wiederholen sollte.

Verwalten von Ausführungen über die CLI

Mithilfe der Azure DevOps CLI können Sie die Pipelineausführungen in Ihrem Projekt auflisten und Details zu einer bestimmten Ausführung anzeigen. Sie können auch Tags in Der Pipelineausführung hinzufügen und löschen.

Voraussetzungen

  • Sie müssen die Azure DevOps CLI-Erweiterung installiert haben, wie unter Erste Schritte mit der Azure DevOps-CLI beschrieben.
  • Melden Sie sich mit bei Azure DevOps an az login.
  • Legen Sie für die Beispiele in diesem Artikel die Standardorganisation mithilfe von az devops configure --defaults organization=YourOrganizationURLfest.

Auflisten von Pipelineausführungen

Listen Sie die Pipelineausführungen in Ihrem Projekt mit dem Befehl az pipelines runs list auf. Informationen zu den ersten Schritten finden Sie unter Erste Schritte mit der Azure DevOps-CLI.

az pipelines runs list [--branch]
                       [--org]
                       [--pipeline-ids]
                       [--project]
                       [--query-order {FinishTimeAsc, FinishTimeDesc, QueueTimeAsc, QueueTimeDesc, StartTimeAsc, StartTimeDesc}]
                       [--reason {all, batchedCI, buildCompletion, checkInShelveset, individualCI, manual, pullRequest, schedule, triggered, userCreated, validateShelveset}]
                       [--requested-for]
                       [--result {canceled, failed, none, partiallySucceeded, succeeded}]
                       [--status {all, cancelling, completed, inProgress, none, notStarted, postponed}]
                       [--tags]
                       [--top]

Optionale Parameter

  • branch: Filtert nach Builds für diesen Branch.
  • org: Url der Azure DevOps-Organisation. Sie können die Standardorganisation mit az devops configure -d organization=ORG_URLkonfigurieren. Erforderlich, wenn nicht als Standard konfiguriert oder mit git configverwendet wird. Beispiel: --org https://dev.azure.com/MyOrganizationName/.
  • pipeline-ids: Durch Leerzeichen getrennte IDs von Definitionen, für die Builds aufgelistet werden sollen.
  • project: Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=NAME_OR_IDkonfigurieren. Erforderlich, wenn nicht als Standard konfiguriert oder mit git configverwendet wird.
  • Abfragereihenfolge: Definieren Sie die Reihenfolge, in der Pipelineausführungen aufgelistet werden. Akzeptierte Werte sind FinishTimeAsc, FinishTimeDesc, QueueTimeAsc, QueueTimeDesc, StartTimeAsc und StartTimeDesc.
  • Grund: Listen Sie nur Builds aus diesem angegebenen Grund auf. Akzeptierte Werte sind batchedCI, buildCompletion, checkInShelveset, individualCI, manual, pullRequest, schedule, triggered, userCreated und validateShelveset.
  • requested-for: Beschränken Sie sich auf die Builds, die für einen angegebenen Benutzer oder eine bestimmte Gruppe angefordert wurden.
  • result: Beschränken Sie sich auf die Builds mit einem angegebenen Ergebnis. Akzeptierte Werte sind canceled, failed, none, partiallySucceededed undsucceeded.
  • status: Beschränken Sie sich auf die Builds mit einem angegebenen Status. Akzeptierte Werte sind alle, abbrechend, abgeschlossen, inProgress, none, notStarted und verschoben.
  • tags: Beschränken Sie sich auf die Builds mit jedem der angegebenen Tags. Leerzeichen getrennt.
  • top: Maximale Anzahl von Builds, die aufgelistet werden sollen.

Beispiel

Der folgende Befehl listet die ersten drei Pipelineausführungen auf, die den Status Abgeschlossen und das Ergebnis erfolgreich aufweisen, und gibt das Ergebnis im Tabellenformat zurück.

az pipelines runs list --status completed --result succeeded --top 3 --output table

Run ID    Number      Status     Result     Pipeline ID    Pipeline Name               Source Branch    Queued Time                 Reason
--------  ----------  ---------  ---------  -------------  --------------------------  ---------------  --------------------------  ------
125       20200124.1  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 18:56:10.067588  manual
123       20200123.2  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:55:56.633450  manual
122       20200123.1  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:48:05.574742  manual

Anzeigen von Details zur Pipelineausführung

Zeigen Sie die Details für eine Pipelineausführung in Ihrem Projekt mit dem Befehl az pipelines runs show an. Informationen zu den ersten Schritten finden Sie unter Erste Schritte mit der Azure DevOps-CLI.

az pipelines runs show --id
                       [--open]
                       [--org]
                       [--project]

Parameter

  • id: Erforderlich. ID der Pipelineausführung.
  • open: Optional. Öffnet die Seite mit den Buildergebnissen in Ihrem Webbrowser.
  • org: Url der Azure DevOps-Organisation. Sie können die Standardorganisation mit az devops configure -d organization=ORG_URLkonfigurieren. Erforderlich, wenn nicht als Standard konfiguriert oder mit git configverwendet wird. Beispiel: --org https://dev.azure.com/MyOrganizationName/.
  • project: Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=NAME_OR_IDkonfigurieren. Erforderlich, wenn nicht als Standard konfiguriert oder mit git configverwendet wird.

Beispiel

Der folgende Befehl zeigt Details für die Pipelineausführung mit der ID 123 und gibt die Ergebnisse im Tabellenformat zurück. Außerdem wird ihr Webbrowser zur Seite mit den Buildergebnissen geöffnet.

az pipelines runs show --id 122 --open --output table

Run ID    Number      Status     Result     Pipeline ID    Pipeline Name               Source Branch    Queued Time                 Reason
--------  ----------  ---------  ---------  -------------  --------------------------  ---------------  --------------------------  --------
123       20200123.2  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:55:56.633450  manual

Hinzufügen eines Tags zur Pipelineausführung

Fügen Sie einer Pipelineausführung in Ihrem Projekt mit dem Befehl az pipelines runs tag add ein Tag hinzu. Informationen zu den ersten Schritten finden Sie unter Erste Schritte mit der Azure DevOps-CLI.

az pipelines runs tag add --run-id
                          --tags
                          [--org]
                          [--project]

Parameter

  • run-id: Erforderlich. ID der Pipelineausführung.
  • tags: Erforderlich. Tags, die der Pipelineausführung hinzugefügt werden sollen (durch Trennzeichen getrennte Werte).
  • org: Url der Azure DevOps-Organisation. Sie können die Standardorganisation mit az devops configure -d organization=ORG_URLkonfigurieren. Erforderlich, wenn nicht als Standard konfiguriert oder mit git configverwendet wird. Beispiel: --org https://dev.azure.com/MyOrganizationName/.
  • project: Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=NAME_OR_IDkonfigurieren. Erforderlich, wenn nicht als Standard konfiguriert oder mit git configverwendet wird.

Beispiel

Der folgende Befehl fügt der Pipelineausführung das Tag YAML mit der ID 123 hinzu und gibt das Ergebnis im JSON-Format zurück.

az pipelines runs tag add --run-id 123 --tags YAML --output json

[
  "YAML"
]

Auflisten von Pipelineausführungstags

Listen Sie die Tags für eine Pipelineausführung in Ihrem Projekt mit dem Befehl az pipelines runs tag list auf. Informationen zu den ersten Schritten finden Sie unter Erste Schritte mit der Azure DevOps-CLI.

az pipelines runs tag list --run-id
                           [--org]
                           [--project]

Parameter

  • run-id: Erforderlich. ID der Pipelineausführung.
  • org: Url der Azure DevOps-Organisation. Sie können die Standardorganisation mit az devops configure -d organization=ORG_URLkonfigurieren. Erforderlich, wenn nicht als Standard konfiguriert oder mit git configverwendet wird. Beispiel: --org https://dev.azure.com/MyOrganizationName/.
  • project: Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=NAME_OR_IDkonfigurieren. Erforderlich, wenn nicht als Standard konfiguriert oder mit git configverwendet wird.

Beispiel

Der folgende Befehl listet die Tags für die ausgeführte Pipeline mit der ID 123 auf und gibt das Ergebnis im Tabellenformat zurück.

az pipelines runs tag list --run-id 123 --output table

Tags
------
YAML

Tag aus Pipelineausführung löschen

Löschen Sie ein Tag aus einer Pipelineausführung in Ihrem Projekt mit dem Befehl az pipelines runs tag delete . Informationen zu den ersten Schritten finden Sie unter Erste Schritte mit der Azure DevOps-CLI.

az pipelines runs tag delete --run-id
                             --tag
                             [--org]
                             [--project]

Parameter

  • run-id: Erforderlich. ID der Pipelineausführung.
  • tag: Erforderlich. Tag, das aus der Pipelineausführung gelöscht werden soll.
  • org: Url der Azure DevOps-Organisation. Sie können die Standardorganisation mit az devops configure -d organization=ORG_URLkonfigurieren. Erforderlich, wenn nicht als Standard konfiguriert oder mit git configverwendet wird. Beispiel: --org https://dev.azure.com/MyOrganizationName/.
  • project: Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=NAME_OR_IDkonfigurieren. Erforderlich, wenn nicht als Standard konfiguriert oder mit git configverwendet wird.

Beispiel

Der folgende Befehl löscht das YAML-Tag aus der Pipelineausführung mit der ID 123.

az pipelines runs tag delete --run-id 123 --tag YAML