Freigeben über

Aufgabentypen und ihre Verwendung

  • Artikel

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

Eine Aufgabe führt eine Aktion in einer Pipeline durch und ist ein gepacktes Skript oder eine Prozedur, die mit einem Satz von Eingaben abstrahiert wurde. Aufgaben sind die Bausteine zum Definieren der Automatisierung in einer Pipeline.

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.

Sie können optional Einzelschrittziele 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.

Wenn Sie einen Auftrag ausführen, werden alle Aufgaben nacheinander auf einem Agent 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.

Weitere Informationen zu den allgemeinen Attributen, die von Aufgaben unterstützt werden, finden Sie in der YAML-Referenz für steps.task.

Benutzerdefinierte Aufgaben

Azure DevOps umfasst integrierte Aufgaben, um grundlegende Build- und Bereitstellungsszenarien zu ermöglichen. Sie können außerdem eigene benutzerdefinierte Token erstellen.

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. Sie können auch Ihre eigenen benutzerdefinierten Erweiterungen schreiben, um Aufgaben zu Azure Pipelines hinzuzufügen.

In YAML-Pipelines verweisen Sie anhand des Namens auf Aufgaben. Wenn ein Name sowohl mit einer In-Box-Aufgabe als auch mit einer benutzerdefinierten Aufgabe übereinstimmt, hat die In-Box-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 Ihre Pipeline automatisch die neue Version. Wenn jedoch eine neue Hauptversion freigegeben wird (z. B. 2.0), verwendet Ihre Pipeline weiterhin weiterhin die von Ihnen angegebene Hauptversion, bis Sie die Pipeline bearbeiten und manuell zur neuen Hauptversion wechseln. Das Protokoll 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.

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

YAML-Pipelines sind in Team Foundation Server (TFS) nicht verfügbar.

Optionen für die Vorgangskontrolle

Jede Aufgabe bietet Ihnen einige Steuerungsoptionen.

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

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.

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

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.

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

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.
  retryCountOnTaskFailure: string # Number of retries if the task fails.

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

Pipelines verfügen möglicherweise über ein Zeitlimit auf Auftragsebene, das zusätzlich zu einem Timeout auf Vorgangsebene angegeben ist. Wenn das Zeitüberschreitungsintervall auf Auftragsebene vor Abschluss Ihres Schritts verstrichen 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 dieser YAML-Datei 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 Agentenpool erfolgreich ist. Wenn Sie über verschiedene Agentenpools verfügen, werden diese Phasen oder Aufträge gleichzeitig ausgeführt. Diese Bedingung ist die Standardeinstellung, wenn in der YAML-Datei keine Bedingung festgelegt ist.

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

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

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

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 er ein target angibt. 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 beträgt 0 erneute Versuche. Weitere Informationen zu Aufgabeneigenschaften finden Sie unter steps.task im YAML-Schema.

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

Hinweis

  • Erfordert Agent-Version 2.194.0 oder höher. In Azure DevOps Server 2022 werden Wiederholungsversuche für agentlose Aufgaben nicht unterstützt. Weitere Informationen finden Sie im Azure DevOps-Dienstupdate vom 16. November 2021 – Automatische Wiederholungen für eine Aufgabe und im Azure DevOps-Dienstupdate vom 14. Juni 2025 – Wiederholungen für Serveraufgaben.
  • Die Wartezeit zwischen den einzelnen Wiederholungsversuchen erhöht sich nach jedem fehlgeschlagenen Versuch. Der erste Wiederholungsversuch erfolgt nach Sekunden.
  • 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.

YAML-Pipelines sind in Team Foundation Server (TFS) nicht verfügbar.

Umgebungsvariablen

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'


- task: Bash@3
  inputs:
     targetType: # 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 Bash3 gefolgt von der entsprechenden Aufgabensyntax handelt. In diesem Beispiel wird der ENV_VARIABLE_NAME-Umgebungsvariable ein Wert zugewiesen, und dieser Wert wird wiedergegeben.

# Using the script shortcut syntax
- script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: "my value"
  displayName: 'echo environment variable'

# Using the task syntax
- task: Bash@2
  inputs:
    script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: "my value"
  displayName: 'echo environment variable'

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

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

pool:
  vmImage: ubuntu-latest

steps:
# Node install
- task: UseNode@1
  displayName: Node install
  inputs:
    version: '16.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.

YAML-Pipelines sind in Team Foundation Server (TFS) nicht verfügbar.

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 In-Box- als auch Marketplace-Aufgaben deaktivieren, sind nur die Aufgaben verfügbar, die Sie mit tfx installieren.

Hilfe und Support