Aufgabentypen -verwendung

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

Hinweis

In Microsoft Team Foundation Server (TFS) 2018 und früheren Versionen werden Build- und Release-Pipelines als Definitionen bezeichnet, Ausführungen werden als Builds bezeichnet, Dienstverbindungen werden als Dienstendpunkte bezeichnet, Stages werden als Umgebungen bezeichnet und Aufträge werden als Phasen bezeichnet.

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 sie auch eine Reihe von Anforderungen an die Pipeline hinzufügen. Die Anforderungen definieren die Voraussetzungen, die für die Ausführung des Vorgangs auf dem Agent installiert werden müssen. Wenn Sie den Build oder die Bereitstellung ausführen, wird ein Agent, der diese Anforderungen erfüllt, ausgewählt.

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

Standardmäßig werden alle Vorgänge im gleichen Kontext ausgeführt, unabhängig davon, ob es sich um den Host oder in einem Auftragscontainer handelt. Sie können optional Schrittziele verwenden, um den Kontext für eine einzelne Aufgabe zu steuern.

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

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

Benutzerdefinierte Aufgaben

Wir bieten einige integrierte Aufgaben , um grundlegende Build- und Bereitstellungsszenarien zu ermöglichen. Wir haben auch Anleitungen zum Erstellen Ihrer eigenen benutzerdefinierten Aufgabe bereitgestellt.

Darüber hinaus bietet Visual Studio Marketplace eine Reihe von Erweiterungen; jede davon, wenn sie auf Ihr Abonnement oder Ihre Sammlung installiert ist, erweitert den Aufgabenkatalog mit einem oder mehreren Aufgaben. Darüber hinaus können Sie ihre eigenen benutzerdefinierten Erweiterungen schreiben, um Aufgaben zu Azure Pipelines oder TFS hinzuzufügen.

In YAML-Pipelines verweisen Sie auf Aufgaben nach Name. Wenn ein Name sowohl mit einer Feldaufgabe als auch mit einem benutzerdefinierten Vorgang übereinstimmt, wird die Feldaufgabe Vorrang haben. Sie können die Aufgaben-GUID oder einen vollqualifizierten Namen für den benutzerdefinierten Vorgang 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 einen Vorgang auf dem Marketplace zu finden myPublisherId und zu finden und myExtensionIdauszuwählen. Die Werte nach der itemName URL-Zeichenfolge sind myPublisherId und myExtensionId. Sie können auch den vollqualifizierten Namen finden, indem Sie die Aufgabe zu einer Releasepipeline hinzufügen und yaML beim Bearbeiten der Aufgabe auswählen.

Aufgabenversionen

Aufgaben sind versioniert, und Sie müssen die Hauptversion des Vorgangs angeben, der in Ihrer Pipeline verwendet wird. Dadurch können Probleme verhindert werden, wenn neue Versionen einer Aufgabe veröffentlicht werden. Aufgaben sind in der Regel abwärtskompatible, aber in einigen Szenarien treten möglicherweise unvorhersehbare Fehler auf, wenn eine Aufgabe automatisch aktualisiert wird.

Wenn eine neue Nebenversion veröffentlicht wird (z. B. 1.2 bis 1.3), wird Ihr Build oder Ihre Version automatisch die neue Version verwenden. Wenn jedoch eine neue Hauptversion veröffentlicht wird (z. B. 2.0), wird Ihr Build oder Ihre Version weiterhin die Hauptversion verwenden, die Sie angegeben haben, bis Sie die Pipeline bearbeiten und manuell in die neue Hauptversion ändern. Das Build- oder Releaseprotokoll enthält eine Warnung, dass eine neue Hauptversion verfügbar ist.

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

In YAML geben Sie die Hauptversion an, die im Aufgabennamen verwendet wird @ . So können Sie z. B. an Version 2 der PublishTestResults Aufgabe anheften:

steps:
- task: PublishTestResults@2

YAML-Pipelines sind in TFS nicht verfügbar.

Aufgabensteuerungsoptionen

Jede Aufgabe bietet Ihnen einige Steuerelementoptionen.

Steuerelementoptionen 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'
  timeoutInMinutes: number  # how long to wait before timing out the task

Steuerelementoptionen 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'
  timeoutInMinutes: number  # how long to wait before timing out the task
  target: string            # 'host' or the name of a container resource to target

Steuerelementoptionen 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: number  # 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/die Phase fortgesetzt wird. Was es tun kann, ist ein Status von erfolgreich oder fehlgeschlagen, und nachgelagerte Vorgänge/Aufträge verfügen jeweils über eine Bedingungsberechnung, mit der sie entscheiden können, ob sie ausführen oder nicht. Die Standardbedingung, die effektiv "ausgeführt wird, wenn wir in einem erfolgreichen Zustand sind".

Führen Sie die Fehlerbehandlung auf eine subtile Weise aus. Es ist effektiv "Tricks" aller nachgelagerten Schritte/Aufträge, um ein Ergebnis als "Erfolg" zu behandeln, um diese Entscheidung zu treffen. Oder um es auf eine andere Art und Weise zu setzen, sagt es: "Berücksichtigen Sie nicht den Fehler dieser Aufgabe, wenn Sie eine Entscheidung über die Bedingung der enthaltenden Struktur treffen".

Der Timeoutzeitraum beginnt, wenn der Vorgang gestartet wird. Es enthält nicht die Zeit, zu der die Aufgabe in der Warteschlange steht oder auf einen Agent wartet.

In diesem YAML wird auch ausgeführt, PublishTestResults@2 wenn der vorherige Schritt aufgrund der erfolgreichen BedingungOrFailed() fehlschlägt.

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

Bedingungen

  • Nur wenn alle vorherigen Abhängigkeiten mit demselben Agentpool erfolgreich waren. Wenn Sie über verschiedene Agentpools verfügen, werden diese Phasen oder Aufträge gleichzeitig ausgeführt. Dies ist die Standardeinstellung, wenn keine Bedingung im YAML festgelegt ist.

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

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

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

Schrittziel

Aufgaben werden in einem Ausführungskontext ausgeführt, der entweder der Agenthost oder ein Container ist. Ein einzelner Schritt kann seinen Kontext außer Kraft setzen, indem er einen target. Verfügbare Optionen sind das Wort host , um den Agenthost sowie alle container zu erreichen, die in der Pipeline definiert sind. Beispiel:

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

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

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

Anzahl der Wiederholungen, wenn der Vorgang fehlgeschlagen ist

Verwenden Sie retryCountOnTaskFailure die Angabe der Anzahl der Wiederholungen, wenn der Vorgang 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. Nicht unterstützt für agentlose Aufgaben.
  • Der fehlgeschlagene Vorgang wird sofort erneut ausgeführt.
  • Es gibt keine Annahme über die Idempotenz des Vorgangs. Wenn die Aufgabe Nebenwirkungen hat (z. B. wenn sie eine externe Ressource teilweise erstellt hat), schlägt sie möglicherweise beim zweiten Ausführen fehl.
  • Es gibt keine Informationen zur Anzahl der wiederholungen, die für die Aufgabe zur Verfügung gestellt wurden.
  • Eine Warnung wird den Vorgangsprotokollen hinzugefügt, die angibt, dass sie fehlgeschlagen ist, bevor sie erneut ausgeführt wird.
  • Alle Versuche, eine Aufgabe erneut auszuführen, werden in der Benutzeroberfläche als Teil desselben Aufgabenknotens angezeigt.

YAML-Pipelines sind in TFS nicht verfügbar.

Umgebungsvariablen

YAML-Pipelines werden in Azure DevOps Server 2019 und höher unterstützt.

Jede Aufgabe verfügt über eine env Eigenschaft, die eine Liste von Zeichenfolgenpaaren ist, die Umgebungsvariablen darstellen, die dem Vorgangsprozess zugeordnet sind.

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, der eine Verknüpfung für die Befehlszeilenaufgabe ist, gefolgt von der entsprechenden Aufgabensyntax. In diesem Beispiel wird der AZURE_DEVOPS_EXT_PAT Umgebungsvariable ein Wert zugewiesen, der zum Authentifizieren mit Azure DevOps 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'

Buildtoolinstallationsprogramme (Azure Pipelines)

Toolinstallationsprogramme ermöglichen es Ihrer Buildpipeline, Ihre Abhängigkeiten zu installieren und zu steuern. Sie haben insbesondere folgende Möglichkeiten:

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

Beispiel: Testen und Überprüfen Der App auf mehreren Versionen von Node.js

Erstellen Sie eine Azure-pipelines.yml-Datei im Basisverzeichnis Ihres Projekts mit den folgenden Inhalten.

pool:
  vmImage: 'Ubuntu 16.04'

steps:
# Node install
- task: NodeTool@0
  displayName: Node install
  inputs:
    versionSpec: '6.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, wie der Build ausgeführt wird. Der Node.js Tool Installer lädt die Node.js Version herunter, wenn sie nicht bereits auf dem Agent vorhanden ist. Das Befehlszeilenskript protokolliert den Speicherort der Node.js Version auf dem Datenträger.

YAML-Pipelines sind in TFS nicht verfügbar.

Aufgaben des Toolinstallationsprogramms

Eine Liste unserer Toolinstallationsaufgaben finden Sie unter Tool-Installationsaufgaben.

Deaktivieren von In-Box- und Marketplace-Aufgaben

Auf der Seite "Organisationseinstellungen" können Sie Marketplace-Aufgaben, Boxaufgaben oder beides deaktivieren. Das Deaktivieren von Marketplace-Aufgaben kann dazu beitragen, die Sicherheit Ihrer Pipelines zu erhöhen . Wenn Sie sowohl box- als auch Marketplace-Aufgaben deaktivieren, sind nur Aufgaben verfügbar, die Sie installieren tfx .

Hilfe und Support