Aufgabentypen und -verwendung

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019 | TFS 2018

Eine Aufgabe ist der Baustein zum Definieren der Automatisierung in einer Pipeline. Eine Aufgabe ist einfach ein verpacktes Skript oder eine Prozedur, die mit einer Reihe von Eingaben abstrahiert wurde.

Wenn Sie Ihrer Pipeline eine Aufgabe hinzufügen, kann auch eine Reihe von Anforderungen zur Pipeline hinzugefügt werden. Die Anforderungen bestimmen die erforderlichen Komponenten, die auf dem Agent installiert werden müssen, damit die Aufgabe ausgeführt werden kann. Wenn Sie den Build oder die Bereitstellung ausführen, wird ein Agent ausgewählt, der diese Anforderungen erfüllt.

Wenn Sie einen Auftrag ausführen, werden alle Aufgaben nacheinander ausgeführt. Informationen zum parallelen Ausführen derselben Aufgaben auf mehreren Agents oder zum Ausführen einiger Aufgaben ohne Verwendung eines Agents finden Sie unter Aufträge.

Standardmäßig werden alle Aufgaben im selben Kontext ausgeführt, unabhängig davon, ob die Ausführung auf dem Host oder in einem Auftragscontainer erfolgt. Optional können Sie Schrittziele verwenden, um den Kontext für eine einzelne Aufgabe zu steuern.

Erfahren Sie mehr darüber, wie Sie mit den integrierten Aufgaben Eigenschaften für eine Aufgabe angeben.

Benutzerdefinierte Aufgaben

Es sind einige integrierte Aufgaben verfügbar, die grundlegende Build- und Bereitstellungsszenarien ermöglichen. Ein Leitfaden zum Erstellen Ihrer eigenen benutzerdefinierten Aufgabe ist ebenfalls verfügbar.

Darüber hinaus bietet Visual Studio Marketplace viele Erweiterungen. Jede dieser Erweiterungen erweitert den Aufgabenkatalog um eine oder mehrere Aufgaben, wenn sie für Ihr Abonnement oder Ihre Sammlung installiert wird. Zudem können Sie eigene benutzerdefinierte Erweiterungen schreiben, um Azure Pipelines oder Team Foundation Server (TFS) Aufgaben hinzuzufügen.

In YAML-Pipelines verweisen Sie anhand des Namens auf Aufgaben. Wenn ein Name sowohl mit einer integrierten Aufgabe als auch einer benutzerdefinierten Aufgabe übereinstimmt, hat die integrierte Aufgabe Vorrang. Sie können die Aufgaben-GUID (Globally Unique Identifier, eindeutiger Bezeichner) oder einen vollqualifizierten Namen für die benutzerdefinierte Aufgabe verwenden, um dieses Risiko zu vermeiden:

steps:
- task: myPublisherId.myExtensionId.myContributionId.myTaskName@1 #format example
- task: qetza.replacetokens.replacetokens-task.replacetokens@3 #working example

Um myPublisherId und myExtensionId zu ermitteln, wählen Sie im Marketplace Abrufen für eine Aufgabe aus. Die Werte nach dem itemName in Ihrer URL-Zeichenfolge sind myPublisherId und myExtensionId. Sie können auch den vollqualifizierten Namen ermitteln, indem Sie die Aufgabe zu einer Releasepipeline hinzufügen und YAML anzeigen auswählen, wenn Sie die Aufgabe bearbeiten.

Aufgabenversionen

Aufgaben werden mit Versionsangaben versehen, und Sie müssen die Hauptversion der Aufgabe angeben, die in Ihrer Pipeline verwendet wird. Dadurch lassen sich Probleme vermeiden, wenn neue Versionen einer Aufgabe freigegeben werden. Aufgaben sind in der Regel abwärtskompatibel. In einigen Szenarien können jedoch unvorhersehbare Fehler auftreten, wenn eine Aufgabe automatisch aktualisiert wird.

Wenn eine neue Nebenversion freigegeben wird (z. B. von 1.2 auf 1.3), verwendet Ihr Build oder Release automatisch die neue Version. Wenn jedoch eine neue Hauptversion freigegeben wird (z. B. 2.0), verwendet Ihr Build oder Release weiterhin die von Ihnen angegebene Hauptversion, bis Sie die Pipeline bearbeiten und manuell zur neuen Hauptversion wechseln. Das Build- oder Releaseprotokoll enthält in diesem Fall eine Warnung, dass eine neue Hauptversion verfügbar ist.

Sie können festlegen, welche Nebenversion verwendet wird, indem Sie die vollständige Versionsnummer einer Aufgabe nach dem @-Zeichen angeben (Beispiel: GoTool@0.3.1). Sie können nur Aufgabenversionen verwenden, die für Ihre Organisation vorhanden sind.

YAML

In YAML geben Sie die Hauptversion mit @ im Aufgabennamen an. So heften Sie z. B. Version 2 der Aufgabe PublishTestResults an:

steps:
- task: PublishTestResults@2

Klassisch

Jede Aufgabe in einer Pipeline verfügt über eine Versionsauswahl, mit der Sie die gewünschte Version auswählen können.

Wenn Sie eine Vorschauversion (z. B . 1.* Vorschau) auswählen, müssen Sie bedenken, dass diese Version noch in der Entwicklung ist und möglicherweise bekannte Probleme aufweist.

Wenn Sie die Version ändern und bei Ihren Builds Probleme auftreten, können Sie die Pipelineänderung auf der Registerkarte Verlauf rückgängig machen. Die Möglichkeit, eine ältere Version einer Releasepipeline wiederherzustellen, ist derzeit nicht verfügbar. Sie müssen die Änderungen an der Releasepipeline manuell rückgängig machen und die Pipeline dann speichern.

Erwägen Sie, die Pipeline zu klonen und die geklonte Pipeline mit der neuen Hauptaufgabenversion zu testen.

Optionen für die Vorgangskontrolle

Jede Aufgabe bietet Ihnen einige Steuerungsoptionen.

YAML

Steuerungsoptionen sind als Schlüssel im task-Abschnitt verfügbar.

- task: string  # reference to a task and version, e.g. "VSBuild@1"
  condition: expression     # see below
  continueOnError: boolean  # 'true' if future steps should run even if this step fails; defaults to 'false'
  enabled: boolean          # whether or not to run this step; defaults to 'true'
  retryCountOnTaskFailure: number # Max number of retries; default is zero
  timeoutInMinutes: string  # how long to wait before timing out the task
  target: string            # 'host' or the name of a container resource to target

Hinweis

Eine bestimmte Aufgabe oder ein Auftrag kann nicht einseitig entscheiden, ob der Auftrag/Schritt fortgesetzt wird. Die Aufgabe bzw. der Auftrag kann einen Status Erfolgreich oder Fehler bereitstellen, und Downstreamaufgaben/-aufträge verfügen über eine Bedingungsberechnung, mit der sie entscheiden können, ob sie ausgeführt werden oder nicht. Die Standardbedingung ist „Ausführen, wenn der Status ‚Erfolgreich‘ lautet“.

Bei Fehler fortsetzen ändert dieses Verhalten geringfügig. Diese Bedingung veranlasst alle Downstreamschritte/-aufträge, jedes Ergebnis beim Treffen dieser Entscheidung als „Erfolgreich“ zu behandeln. Anders ausgedrückt: Die Bedingung weist sie an, den Fehler dieser Aufgabe bei der Entscheidung über den Zustand der enthaltenden Struktur nicht zu berücksichtigen.

Der Timeoutzeitraum beginnt, wenn die Ausführung der Aufgabe gestartet wird. Die Zeit, in der die Aufgabe sich in der Warteschlange befindet oder auf einen Agent wartet, wird nicht berücksichtigt.

Hinweis

Für Pipelines kann zusätzlich zu einem Timeout auf Vorgangsebene ein Timeout auf Auftragsebene angegeben werden. Wenn das Timeoutintervall auf Auftragsebene verstrichen ist, bevor der Schritt abgeschlossen ist, wird der ausgeführte Auftrag beendet, auch wenn der Schritt mit einem längeren Timeoutintervall konfiguriert ist. Weitere Informationen finden Sie unter Timeouts.

In diesem YAML-Beispiel wird PublishTestResults@2 auch dann ausgeführt, wenn der vorherige Schritt aufgrund der succeededOrFailed()-Bedingung fehlschlägt.

steps:
- task: UsePythonVersion@0
  inputs:
    versionSpec: '3.x'
    architecture: 'x64'
- task: PublishTestResults@2
  inputs:
    testResultsFiles: "**/TEST-*.xml"
  condition: succeededOrFailed()

Bedingungen

• Nur, wenn die Überprüfung aller vorherigen direkten und indirekten Abhängigkeiten mit demselben Agentpool erfolgreich war. Wenn Sie über verschiedene Agentpools verfügen, werden diese Phasen oder Aufträge gleichzeitig ausgeführt. Dies ist die Standardeinstellung, wenn in der YAML-Datei keine Bedingung festgelegt ist.

• Auch wenn eine vorherige Abhängigkeit fehlgeschlagen ist, außer wenn die Ausführung abgebrochen wurde. Verwenden Sie für diese Bedingung succeededOrFailed() in der YAML-Datei.

• Auch wenn eine vorherige Abhängigkeit fehlgeschlagen ist, auch wenn die Ausführung abgebrochen wurde. Verwenden Sie für diese Bedingung always() in der YAML-Datei.

• Nur wenn eine vorherige Abhängigkeit fehlgeschlagen ist. Verwenden Sie für diese Bedingung failed() in der YAML-Datei.

• Benutzerdefinierte Bedingungen, die aus Ausdrücken bestehen.

Schrittziel

Aufgaben werden in einem Ausführungskontext ausgeführt, bei dem es sich entweder um den Agent-Host oder einen Container handelt. Ein einzelner Schritt kann seinen Kontext überschreiben, indem ein target angegeben wird. Verfügbare Optionen sind das Wort host, um den Agent-Host als Ziel anzugeben, und beliebige Container, die in der Pipeline definiert sind. Beispiel:

resources:
  containers:
  - container: pycontainer
    image: python:3.11

steps:
- task: SampleTask@1
  target: host
- task: AnotherTask@1
  target: pycontainer

Hier wird SampleTask auf dem Host ausgeführt und AnotherTask in einem Container.

Anzahl der Wiederholungen, wenn der Task fehlgeschlagen ist

Verwenden Sie retryCountOnTaskFailure, um die Anzahl von Wiederholungen anzugeben, die ausgeführt werden, wenn die Aufgabe fehlschlägt. Der Standardwert ist 0.

- task: <name of task>
   retryCountOnTaskFailure: <max number of retries>
   ...

Hinweis

• Erfordert Agent-Version 2.194.0 oder höher. Wird für Aufgaben ohne Agent nicht unterstützt.
• Die Wiederholungen der fehlerhaften Aufgabe in Sekunden. Die Wartezeit zwischen den einzelnen Wiederholungsversuchen erhöht sich nach jedem fehlgeschlagenen Versuch.
• Es gibt keine Annahmen bezüglich der Idempotenz der Aufgabe. Wenn die Aufgabe Nebenfolgen hat (wenn sie z. B. eine externe Ressource teilweise erstellt hat), schlägt sie möglicherweise bei der zweiten Ausführung fehl.
• Es werden keine Informationen zur Wiederholungsanzahl für die Aufgabe verfügbar gemacht.
• Den Aufgabenprotokollen wird eine Warnung hinzugefügt, dass die Aufgabe fehlgeschlagen ist, bevor sie wiederholt wird.
• Alle Versuche zur erneuten Ausführung einer Aufgabe werden auf der Benutzeroberfläche unter demselben Aufgabenknoten angezeigt.

Klassisch

Aktiviert

Deaktivieren Sie dieses Kontrollkästchen, um eine Aufgabe zu deaktivieren. Dies ist nützlich, wenn Sie eine Aufgabe für Tests oder bestimmte Bereitstellungen vorübergehend aus dem Prozess entfernen möchten.

Tipp

Sie können auch mit der rechten Maustaste auf die Aufgabe klicken, um diese Einstellung umzuschalten.

Timeout

Das Timeout für diese Aufgabe in Minuten. Der Standardwert ist null (unendliches Timeout). Wenn Sie einen anderen Wert als null festlegen, wird die Einstellung für den übergeordneten Aufgabenauftrag außer Kraft gesetzt. Der Timeoutzeitraum beginnt, wenn die Ausführung der Aufgabe gestartet wird. Die Zeit, in der die Aufgabe sich in der Warteschlange befindet oder auf einen Agent wartet, wird nicht berücksichtigt.

Optionen in Azure Pipelines

Bei Fehler fortsetzen (teilweise erfolgreich)

Wählen Sie diese Option aus, wenn nachfolgende Aufgaben im selben Auftrag ggf. auch dann ausgeführt werden sollen, wenn diese Aufgabe fehlschlägt. Der Build oder die Bereitstellung ist höchstens teilweise erfolgreich. Ob nachfolgende Aufgaben ausgeführt werden, hängt von der Einstellung Aufgabe ausführen ab.

Anzahl der Wiederholungen, wenn der Task fehlgeschlagen ist

Geben Sie die Anzahl von Wiederholungen an, die ausgeführt werden, wenn die Aufgabe fehlschlägt. Der Standardwert ist 0.

Hinweis

• Die Wiederholungen der fehlerhaften Aufgabe in Sekunden. Die Wartezeit zwischen den einzelnen Wiederholungsversuchen erhöht sich nach jedem fehlgeschlagenen Versuch.
• Es gibt keine Annahmen bezüglich der Idempotenz der Aufgabe. Wenn die Aufgabe Nebenfolgen hat (wenn sie z. B. eine externe Ressource teilweise erstellt hat), schlägt sie möglicherweise bei der zweiten Ausführung fehl.
• Es werden keine Informationen zur Wiederholungsanzahl für die Aufgabe verfügbar gemacht.
• Den Aufgabenprotokollen wird eine Warnung hinzugefügt, dass die Aufgabe fehlgeschlagen ist, bevor sie wiederholt wird.
• Alle Versuche zur erneuten Ausführung einer Aufgabe werden auf der Benutzeroberfläche unter demselben Aufgabenknoten angezeigt.

Aufgabe ausführen

Wählen Sie die Bedingung für die Ausführung dieser Aufgabe aus:

• Nur, wenn die Überprüfung aller vorherigen direkten und indirekten Abhängigkeiten mit demselben Agentpool erfolgreich war. Wenn Sie über verschiedene Agentpools verfügen, werden diese Phasen oder Aufträge gleichzeitig ausgeführt. Dies ist die Standardeinstellung, wenn in der YAML-Datei keine Bedingung festgelegt ist.

• Auch wenn eine vorherige Abhängigkeit fehlgeschlagen ist, außer wenn die Ausführung abgebrochen wurde. Verwenden Sie für diese Bedingung succeededOrFailed() in der YAML-Datei.

• Auch wenn eine vorherige Abhängigkeit fehlgeschlagen ist, auch wenn die Ausführung abgebrochen wurde. Verwenden Sie für diese Bedingung always() in der YAML-Datei.

• Nur wenn eine vorherige Abhängigkeit fehlgeschlagen ist. Verwenden Sie für diese Bedingung failed() in der YAML-Datei.

• Benutzerdefinierte Bedingungen, die aus Ausdrücken bestehen.

Hinweis

Wenn Sie Aufgaben in Fällen ausführen, in denen der Build abgebrochen wird, müssen Sie genügend Zeit angeben, damit diese Aufgaben die Pipelineoptionen ausführen können.

Optionen in TFS 2018 und höher

Bei Fehler fortsetzen (teilweise erfolgreich)

Wählen Sie diese Option aus, wenn nachfolgende Aufgaben im selben Auftrag auch dann ausgeführt werden sollen, wenn diese Aufgabe fehlschlägt. Der Build oder die Bereitstellung ist höchstens teilweise erfolgreich.

Immer ausführen

Aktivieren Sie dieses Kontrollkästchen, wenn die Aufgabe auch dann ausgeführt werden soll, wenn der Build oder die Bereitstellung fehlschlägt.

Umgebungsvariablen

YAML

Jede Aufgabe verfügt über eine env-Eigenschaft, bei der es sich um eine Liste von Zeichenfolgenpaaren handelt, die dem Aufgabenprozess zugeordnete Umgebungsvariablen darstellen.

task: AzureCLI@2
displayName: Azure CLI
inputs: # Specific to each task
env:
  ENV_VARIABLE_NAME: value
  ENV_VARIABLE_NAME2: value
  ...

Im folgenden Beispiel wird der script-Schritt ausgeführt, bei dem es sich um eine Verknüpfung für die Befehlszeilenaufgabe gefolgt von der entsprechenden Aufgabensyntax handelt. In diesem Beispiel wird der Umgebungsvariablen AZURE_DEVOPS_EXT_PAT ein Wert zugewiesen, der zur Authentifizierung mit der Azure DevOps-Befehlszeilenschnittstelle (Command Line Interface, CLI) verwendet wird.

# Using the script shortcut syntax
- script: az pipelines variable-group list --output table
  env:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'List variable groups using the script step'

# Using the task syntax
- task: CmdLine@2
  inputs:
    script: az pipelines variable-group list --output table
  env:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'List variable groups using the command line task'

Klassisch

Sie können den Abschnitt Umgebungsvariablen des Aufgaben-Editors verwenden, um mit Umgebungsvariablen zu arbeiten.

Buildtool-Installationsprogramme (Azure Pipelines)

Toolinstallationsprogramme ermöglichen Ihrer Buildpipeline das Installieren und Steuern Ihrer Abhängigkeiten. Insbesondere bestehen die folgenden Möglichkeiten:

• Installieren Sie ein Tool oder eine Runtime genau zum richtigen Zeitpunkt für Ihren CI-Build im laufenden Betrieb (selbst auf von Microsoft gehosteten Agents).

• Überprüfen Sie Ihre App oder Bibliothek anhand mehrerer Versionen einer Abhängigkeit (z. B. Node.js).

Beispielsweise können Sie Ihre Buildpipeline dafür einrichten, Ihre App für mehrere Versionen von Node.js auszuführen und zu überprüfen.

Beispiel: Testen und Überprüfen Ihrer App für mehrere Versionen von Node.js

YAML

Erstellen Sie im Basisverzeichnis Ihres Projekts eine Datei „azure-pipelines.yml“ mit dem folgenden Inhalt.

pool:
  vmImage: ubuntu-latest

steps:
# Node install
- task: NodeTool@0
  displayName: Node install
  inputs:
    versionSpec: '12.x' # The version we're installing
# Write the installed version to the command line
- script: which node

Erstellen Sie eine neue Buildpipeline, und führen Sie sie aus. Beobachten Sie die Ausführung des Builds. Der Installer für Node.js-Tools lädt die Node.js-Version herunter, wenn sie noch nicht auf dem Agent vorhanden ist. Das Befehlszeilenskript protokolliert den Speicherort der Node.js-Version auf dem Datenträger.

Klassisch

Registerkarte „Aufgaben“

Erstellen Sie eine neue Buildpipeline (beginnen Sie mit einem leeren Prozess), um dies auszuprobieren.

Wenden Sie die folgenden Agent-Einstellungen an:

1. Legen Sie Parallelität auf Multikonfiguration fest.

2. Geben Sie Multiplikatoren an:

NodeVersionSpec

3. Legen Sie Maximale Anzahl von Agents auf 2 fest.

Fügen Sie die folgenden Aufgaben hinzu:

Tool: Node.js-Installer

• Versionsangabe:

  $(NodeVersionSpec)
  

Hilfsprogramm: Befehlszeile

• Skript (bei der Ausführung auf einem Windows-Agent)

  where node
  

• Skript (bei der Ausführung auf einem macOS- oder Linux-Agent)

  which node
  

Registerkarte „Variablen“

Definieren Sie auf der Registerkarte „Variablen“ die folgende Variable:

Name	Wert	Zur Warteschlangenzeit festlegbar
NodeVersionSpec	10.x, 12.x	Ausgewählt

Speichern und in Warteschlange einreihen

Wählen Sie Speichern und in Warteschlange einreihen aus. Beobachten Sie die Ausführung von zwei Builds. Der Installer für Node.js-Tools lädt jede der Node.js-Versionen herunter, wenn sie noch nicht auf dem Agent vorhanden sind. Die Befehlszeilenaufgabe protokolliert den Speicherort der Node.js-Version auf dem Datenträger.

Aufgaben im Toolinstallationsprogramm

Eine Liste der Aufgaben im Toolinstallationsprogramm finden Sie hier.

Deaktivieren von integrierten Aufgaben und Marketplace-Aufgaben

Auf der Seite „Organisationseinstellungen“ können Sie Marketplace-Aufgaben und/oder integrierte Aufgaben deaktivieren. Das Deaktivieren von Marketplace-Aufgaben kann die Sicherheit Ihrer Pipelines erhöhen. Wenn Sie sowohl integrierte Aufgaben als auch Marketplace-Aufgaben deaktivieren, sind nur Aufgaben verfügbar, die Sie mithilfe von tfx installieren.

Verwandte Artikel

• Aufträge
• Aufgabengruppen
• Katalog der integrierten Aufgaben

Hilfe und Support

• Siehe unsere Seite zur Problembehandlung
• Informieren Sie sich in unserer Azure DevOps-Entwicklercommunity über Stack Overflow und posten Sie Ihre Fragen, suchen Sie nach Antworten oder schlagen Sie eine Funktion vor. Seite Support.