Pipelineausführungssequenz
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Ausführungen stellen jeweils einen Durchlauf 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. Ausführungen sind sowohl für CI- (Continuous Integration) als auch für CD-Pipelines (Continuous Integration) zentral.
Wenn Sie eine Pipeline ausführen, geschehen viele Dinge im Hintergrund. Obwohl Sie oft nichts darüber wissen müssen, ist es manchmal nützlich, die einzelnen Elemente zu kennen. Auf allgemeiner Ebene führt Azure Pipelines Folgendes aus:
- Verarbeiten der Pipeline
- Anfordern von Agents zum Ausführen von Aufträgen
- Übergeben von Aufträgen an Agents und Sammeln der Ergebnisse
Auf der Agent-Seite führt ein Agent für jeden Auftrag Folgendes aus:
- Vorbereiten auf den Auftrag
- Ausführen der einzelnen Schritte im Auftrag
- Melden der Ergebnisse an Azure Pipelines
Aufträge können erfolgreich, fehlerhaft oder abgebrochen beendet werden. Es gibt auch Situationen, in denen ein Auftrag möglicherweise nicht abgeschlossen wird. Kenntnisse über die Ursachen dieses Zustands helfen Ihnen beim Beheben von Problemen.
Nun werden die einzelnen Aktionen einzeln beschrieben.
Verarbeiten der Pipeline
Um eine Pipeline in eine Ausführung umzuwandeln, führt Azure Pipelines mehrere Schritte in dieser Reihenfolge durch:
- Zunächst werden Vorlagen erweitert und Vorlagenausdrücke ausgewertet.
- Als Nächstes werden Abhängigkeiten auf Stageebene ausgewertet, um die ersten auszuführenden Stages zu ermitteln.
- Für jede Stage, die für die Ausführung ausgewählt wurde, geschehen zwei Dinge:
- Alle in allen Aufträgen verwendeten Ressourcen werden gesammelt und überprüft, damit die Autorisierung ausgeführt werden kann.
- Die Abhängigkeiten werden auf Auftragsebene ausgewertet, um die ersten auszuführenden Aufträge zu ermitteln.
- Für jeden auszuführenden Auftrag werden Mehrfachkonfigurationen (
strategy: matrixoderstrategy: parallelin YAML) in mehrere Laufzeitaufträge erweitert. - Für jeden Laufzeitauftrag werden Bedingungen ausgewertet, um zu entscheiden, ob dieser Auftrag für die Ausführung qualifiziert ist.
- Für jeden berechtigten Laufzeitauftrag wird ein Agent angefordert.
Nach Abschluss der Laufzeitaufträge überprüft Azure Pipelines, ob neue Aufträge ausgeführt werden können. In diesem Fall werden die Schritte 4 bis 6 mit den neuen Aufträgen wiederholt. Ebenso werden die Schritte 2 bis 6 mit dem Abschluss der Stages für eventuelle neue Stages 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.
Auch ein weiteres häufiges Problem wird beantwortet: 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 zwar verwendet werden, das gilt aber nur für explizit in der Pipeline enthaltene. 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 bilden eine Ausnahme, da sie auf dem Azure Pipelines-Server ausgeführt werden.) Von Microsoft gehostete und selbstgehostete Agentpools funktionieren etwas anders.
Poolanforderungen nach von Microsoft gehosteten Agents
Zunächst überprüft der Dienst die parallelen Aufträge Ihrer Organisation. Er summiert alle ausgeführten Aufträge für alle 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 warten, bis ein Slot frei wird.
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 angeforderten vmImage (in YAML) oder Poolnamen (im klassischen Editor) wird ein Agent ausgewählt.
Alle Agents im Microsoft-Pool sind neue virtuelle Computer, die noch keine Pipelines ausgeführt haben. Nach Abschluss des Auftrags wird die Agent-VM verworfen.
Poolanforderungen nach selbstgehosteten Agents
Ähnlich wie beim von Microsoft gehosteten Pool überprüft der Dienst zunächst die parallelen Aufträge Ihrer Organisation. Er summiert alle ausgeführten Aufträge für alle selbstgehosteten Agents und vergleicht diese mit der Anzahl der erworbenen parallelen Aufträge. Wenn keine parallelen Slots verfügbar sind, muss der Auftrag warten, bis ein Slot frei wird.
Sobald ein paralleler Slot verfügbar ist, wird der selbstgehostete Pool auf einen kompatiblen Agent untersucht. Selbstgehostete Agents bieten Fähigkeiten, Zeichenfolgen, die angeben, dass eine bestimmte Software installiert oder Einstellungen konfiguriert sind. Die Pipeline weist Anforderungen auf, d. h. erforderliche Fähigkeiten zum Ausführen des Auftrags. Wenn kein freier Agent gefunden werden kann, dessen Fähigkeiten den Anforderungen der Pipeline entsprechen, wartet der Auftrag weiter. Wenn im Pool keine Agents vorhanden sind, deren Fähigkeiten den Anforderungen entsprechen, tritt bei dem Auftrag ein Fehler auf.
Selbstgehostete Agents werden in der Regel zwischen den Ausführungen wiederverwendet. Bei selbstgehosteten Agents kann ein Pipelineauftrag Nebenwirkungen aufweisen, z. B. das Aufwärmen von Caches oder die bereits im lokalen Repository verfügbare Commits.
Vorbereiten der Ausführung eines Auftrags
Nachdem ein Agent einen Auftrag angenommen hat, muss einige Vorbereitung durchgeführt werden. Der Agent lädt alle zum Ausführen des Auftrags erforderlichen Aufgaben herunter (und speichert sie für das nächste Mal zwischen). Es erstellt einen Arbeitsspeicherplatz auf dem Datenträger, in dem Quellcode, Artefakte und Ausgaben der Ausführung gespeichert werden. Anschließend werden Schritte ausgeführt.
Ausführung der einzelnen Schritte
Die Schritte werden sequenziell nacheinander ausgeführt. Bevor ein Schritt beginnen kann, müssen alle vorherigen Schritte abgeschlossen (oder übersprungen) werden.
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. zum Ändern des Systempfads und Erstellen neuer Pipelinevariablen.
Jeder Schritt wird in einem eigenen Prozess ausgeführt, wobei er von der Umgebung, die vorherige Schritte hinterlassen haben, isoliert wird. 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: die Protokollierungsbefehle. Wenn eine Aufgabe oder ein Skript einen Protokollierungsbefehl in die Standardausgabe 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 die neue Variable myVar mit dem Wert myValue festzulegen, kann ein Skript folgendermaßen vorgehen:
echo '##vso[task.setVariable variable=myVar]myValue'
Write-Host "##vso[task.setVariable variable=myVar]myValue"
Berichten und Sammeln von Ergebnissen
Jeder Schritt kann Warnungen, Fehler und Ausfälle melden.
Fehler und Warnungen werden an die Pipelinezusammenfassungsseite gemeldet und die Aufgabe dann als „erfolgreich mit Problemen“ gekennzeichnet.
Ausfälle werden ebenfalls an die Zusammenfassungsseite gemeldet, dabei wird die Aufgabe jedoch als „fehlerhaft“ markiert.
Ein Schritt gilt ein Fehler, wenn er explizit einen Fehler meldet (mithilfe eines ##vso-Befehls) oder das Skript mit einem anderen Exitcode als 0 (null) beendet.
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 einsehen. Am Ende jedes Schritts wird auch die gesamte Ausgabe des Schritts als Protokolldatei hochgeladen. Protokolle können nach Abschluss der Pipeline heruntergeladen werden. Weitere Elemente, die der Agent hochladen kann, sind Artefakte und Testergebnisse. Diese sind auch nach Abschluss der Pipeline verfügbar.
Status und Bedingungen
Der Agent verfolgt den Erfolg oder Fehler jedes Schritts nach. Wenn Schritte erfolgreich mit Problemen sind oder ein Fehler auftritt, wird die Status des Auftrags aktualisiert. Der Auftrag spiegelt immer das schlechteste Ergebnis der einzelnen Schritte wider: Wenn bei einem Schritt ein Fehler auftritt, gilt dies auch für den Auftrag.
Vor dem Ausführen eines Schritts überprüft der Agent die Bedingung dieses Schritts, um zu ermitteln, ob er ausgeführt werden soll. Standardmäßig wird ein Schritt nur ausgeführt, wenn der Status des Auftrags erfolgreich oder erfolgreich mit Problemen lautet. Bei vielen Aufträgen müssen Bereinigungsschritte unabhängig von anderen Geschehnissen ausgeführt werden, damit sie die Bedingung „always()“ angeben können. Es kann für Bereinigungsschritte auch festgelegt werden, dass sie nur bei einem Abbruch ausgeführt werden. Mit einem erfolgreichen Bereinigungsschritt kann der Auftrag nicht vor einem Fehler bewahrt werden. Aufträge können nach dem Wechsel in einen Fehlerzustand nie zum Erfolgsstatus zurückkehren.
Timeouts und Trennungen
Jeder Auftrag weist ein Timeout auf. Wenn der Auftrag nicht in der angegebenen Zeit abgeschlossen wurde, bricht der Server den Auftrag ab. Er versucht, dem Agent zu signalisieren, dass er angehalten wird, und markiert den Auftrag als abgebrochen. Auf der Agent-Seite werden dann alle verbleibenden Schritte abgebrochen und alle verbleibenden Ergebnisse hochgeladen.
Aufträge haben eine als Abbruchtimeout bezeichnete Nachfrist, in der alle Arbeiten nach dem Abbrechen abgeschlossen werden können. (Denken Sie daran, dass Schritte so markiert werden können, dass sie auch bei einem Abbruch ausgeführt werden.) Wenn der Agent nach dem Timeout plus dem Abbruchtimeout nicht gemeldet hat, dass die Arbeit beendet wurde, markiert der Server den Auftrag als fehlerhaft.
Da Azure Pipelines Arbeit an Agent-Computer verteilt, reagieren Agents möglicherweise von Zeit zu Zeit nicht mehr auf den Server. Dies kann vorkommen, wenn der Hostcomputer des Agents nicht mehr vorhanden ist (Stromausfall, Deaktivieren der VM) oder wenn ein Netzwerkfehler auftritt. Als Hilfe beim Erkennen dieser Bedingungen sendet der Agent einmal pro Minute eine Heartbeatnachricht, um den Server darüber zu informieren, dass er noch in Betrieb ist. Wenn der Server für einen Zeitraum von fünf Minuten keinen Heartbeat empfängt, geht er davon aus, dass der Agent nicht wieder aktiviert wird. Der Auftrag wird als fehlerhaft markiert, sodass Benutzer*innen wissen, dass sie die Pipeline wiederholen müssen.
Verwalten von Ausführungen über die Befehlszeilenschnittstelle
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 Ihrer Pipelineausführung hinzufügen und löschen.
Voraussetzungen
- Bei Ihnen muss die Azure DevOps CLI-Erweiterung installiert sein, wie unter Erste Schritte mit Azure DevOps CLI beschrieben.
- Melden Sie sich mithilfe von
az loginbei Azure DevOps an. - Legen Sie für die Beispiele in diesem Artikel mithilfe von
az devops configure --defaults organization=YourOrganizationURLdie Standardorganisation fest.
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 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: Filtern nach Builds für diesen Branch.
- org: Azure DevOps-Organisations-URL. Sie können die Standardorganisation mit
az devops configure -d organization=ORG_URLkonfigurieren. Erforderlich, wenn nicht als Standard konfiguriert oder mithilfe vongit configübernommen. 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, sofern nicht als Standard konfiguriert oder mithilfe vongit configübernommen. - query-order: Definieren der Reihenfolge, in der Pipelineausführungen aufgelistet werden. Zulässige Werte sind FinishTimeAsc, FinishTimeDesc, QueueTimeAsc, QueueTimeDesc, StartTimeAsc und StartTimeDesc.
- reason: ausschließliches Auflisten von Builds aus diesem angegebenen Grund. Zulässige Werte sind batchedCI, buildCompletion, checkInShelveset, individualCI, manual, pullRequest, schedule, triggered, userCreated und validateShelveset.
- requested-for: Beschränken auf die Builds, die für eine*n angegebene*n Benutzer*in oder eine bestimmte Gruppe angefordert wurden.
- result: Beschränken auf die Builds mit einem angegebenen Ergebnis. Zulässige Werte sind canceled, failed, none, partiallySucceeded und succeeded.
- status: Beschränken auf die Builds mit einem angegebenen Status. Zulässige Werte sind all, cancelling, completed, inProgress, none, notStarted und postponed.
- tags: Beschränken auf die Builds mit allen 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 completed (abgeschlossen) und das Ergebnis succeeded (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 Azure DevOps CLI.
az pipelines runs show --id
[--open]
[--org]
[--project]
Parameter
- id: erforderlich. ID der Pipelineausführung.
- open: optional. Öffnet die Seite „Buildergebnisse“ in Ihrem Webbrowser.
- org: Azure DevOps-Organisations-URL. Sie können die Standardorganisation mit
az devops configure -d organization=ORG_URLkonfigurieren. Erforderlich, wenn nicht als Standard konfiguriert oder mithilfe vongit configübernommen. 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 mithilfe vongit configübernommen.
Beispiel
Der folgende Befehl zeigt Details für die Pipelineausführung mit der ID 123 an und gibt die Ergebnisse im Tabellenformat zurück. Außerdem wird der Webbrowser mit der Seite „Buildergebnisse“ 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 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 Kommas getrennte Werte).
- org: Azure DevOps-Organisations-URL. Sie können die Standardorganisation mit
az devops configure -d organization=ORG_URLkonfigurieren. Erforderlich, wenn nicht als Standard konfiguriert oder mithilfe vongit configübernommen. 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 mithilfe vongit configübernommen.
Beispiel
Der folgende Befehl fügt das Tag YAML der Pipelineausführung 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ührungs-Tags
Listen Sie die Tags für eine Pipelineausführung in Ihrem Projekt mit dem Befehl az pipelines runs tag list an. Informationen zu den ersten Schritten finden Sie unter Erste Schritte mit Azure DevOps CLI.
az pipelines runs tag list --run-id
[--org]
[--project]
Parameter
- run-id: erforderlich. ID der Pipelineausführung.
- org: Azure DevOps-Organisations-URL. Sie können die Standardorganisation mit
az devops configure -d organization=ORG_URLkonfigurieren. Erforderlich, wenn nicht als Standard konfiguriert oder mithilfe vongit configübernommen. 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 mithilfe vongit configübernommen.
Beispiel
Der folgende Befehl listet die Tags für die Pipelineausführung mit der ID 123 an und gibt die Ergebnisse im Tabellenformat zurück.
az pipelines runs tag list --run-id 123 --output table
Tags
------
YAML
Löschen eines Tags aus einer Pipelineausführung
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 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: Azure DevOps-Organisations-URL. Sie können die Standardorganisation mit
az devops configure -d organization=ORG_URLkonfigurieren. Erforderlich, wenn nicht als Standard konfiguriert oder mithilfe vongit configübernommen. 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 mithilfe vongit configübernommen.
Beispiel
Der folgende Befehl löscht das Tag YAML aus der Pipelineausführung mit der ID 123.
az pipelines runs tag delete --run-id 123 --tag YAML
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für