Angeben von Aufträgen in Ihrer Pipeline

Azure DevOps Services | Azure DevOps Server 2022 – 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.

Sie können Ihre Pipeline in Aufträgen organisieren. Jede Pipeline verfügt über mindestens einen Auftrag. Ein Auftrag ist eine Reihe von Schritten, die sequenziell als Einheit ausgeführt werden. Mit anderen Worten, ein Auftrag ist die kleinste Arbeitseinheit, die für die Ausführung geplant werden kann.

Sie können Ihre Build- oder Releasepipeline in Aufträgen organisieren. Jede Pipeline verfügt über mindestens einen Auftrag. Ein Auftrag ist eine Reihe von Schritten, die sequenziell als Einheit ausgeführt werden. Mit anderen Worten, ein Auftrag ist die kleinste Arbeitseinheit, die für die Ausführung geplant werden kann.

Hinweis

Sie müssen TFS 2018.2 installieren, um Aufträge in Buildprozessen zu verwenden. In TFS 2018 RTM können Sie Aufträge in Releasebereitstellungsprozessen verwenden.

Definieren eines einzelnen Auftrags

YAML

Im einfachsten Fall verfügt eine Pipeline über einen einzelnen Auftrag. In diesem Fall müssen Sie das job Schlüsselwort nicht explizit verwenden, es sei denn, Sie verwenden eine Vorlage. Sie können die Schritte direkt in Ihrer YAML-Datei angeben.

Diese YAML-Datei enthält einen Auftrag, der auf einem Microsoft gehosteten Agent ausgeführt wird und ausgibtHello world.

pool:
  vmImage: 'ubuntu-latest'
steps:
- bash: echo "Hello world"

Sie können zusätzliche Eigenschaften für diesen Auftrag angeben. In diesem Fall können Sie das job Schlüsselwort verwenden.

jobs:
- job: myJob
  timeoutInMinutes: 10
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - bash: echo "Hello world"

Ihre Pipeline verfügt möglicherweise über mehrere Aufträge. Verwenden Sie in diesem Fall das jobs Schlüsselwort.

jobs:
- job: A
  steps:
  - bash: echo "A"

- job: B
  steps:
  - bash: echo "B"

Ihre Pipeline kann mehrere Phasen mit jeweils mehreren Aufträgen aufweisen. Verwenden Sie in diesem Fall das stages Schlüsselwort.

stages:
- stage: A
  jobs:
  - job: A1
  - job: A2

- stage: B
  jobs:
  - job: B1
  - job: B2

Die vollständige Syntax zum Angeben eines Auftrags lautet:

- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  strategy:
    parallel: # parallel strategy
    matrix: # matrix strategy
    maxParallel: number # maximum number simultaneous matrix legs to run
    # note: `parallel` and `matrix` are mutually exclusive
    # you may specify one or the other; including both is an error
    # `maxParallel` is only valid with `matrix`
  continueOnError: boolean  # 'true' if future jobs should run even if this job fails; defaults to 'false'
  pool: pool # agent pool
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  container: containerReference # container to run this job inside
  timeoutInMinutes: number # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: number # how much time to give 'run always even if cancelled tasks' before killing them
  variables: { string: string } | [ variable | variableReference ] 
  steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
  services: { string: string | container } # container resources to run as a service container

Die vollständige Syntax zum Angeben eines Auftrags lautet:

- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  strategy:
    parallel: # parallel strategy
    matrix: # matrix strategy
    maxParallel: number # maximum number simultaneous matrix legs to run
    # note: `parallel` and `matrix` are mutually exclusive
    # you may specify one or the other; including both is an error
    # `maxParallel` is only valid with `matrix`
  continueOnError: boolean  # 'true' if future jobs should run even if this job fails; defaults to 'false'
  pool: pool # agent pool
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  container: containerReference # container to run this job inside
  timeoutInMinutes: number # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: number # how much time to give 'run always even if cancelled tasks' before killing them
  variables: { string: string } | [ variable | variableReference ] 
  steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
  services: { string: string | container } # container resources to run as a service container
  uses: # Any resources (repos or pools) required by this job that are not already referenced
    repositories: [ string ] # Repository references to Azure Git repositories
    pools: [ string ] # Pool names, typically when using a matrix strategy for the job

Wenn die primäre Absicht Ihres Auftrags darin besteht, Ihre App bereitzustellen (anstatt Ihre App zu erstellen oder zu testen), können Sie einen speziellen Typ von Auftrag namens Bereitstellungsauftrag verwenden.

Die Syntax für einen Bereitstellungsauftrag lautet:

- deployment: string        # instead of job keyword, use deployment keyword
  pool:
    name: string
    demands: string | [ string ]
  environment: string
  strategy:
    runOnce:
      deploy:
        steps:
        - script: echo Hi!

Obwohl Sie Schritte für Bereitstellungsaufgaben in einem jobhinzufügen können, wird empfohlen, stattdessen einen Bereitstellungsauftrag zu verwenden. Ein Bereitstellungsauftrag hat einige Vorteile. Beispielsweise können Sie eine Bereitstellung in einer Umgebung durchführen, die Vorteile wie die Möglichkeit bietet, den Verlauf ihrer Bereitstellung anzuzeigen.

YAML wird in TFS nicht unterstützt.

Klassisch

Um Ihrer Buildpipeline Aufträge hinzuzufügen, bearbeiten Sie die Pipeline auf der Seite Pipelines. Wählen Sie ... aus, um einen Auftrag hinzuzufügen.

Um Ihrer Releasepipeline Aufträge hinzuzufügen, bearbeiten Sie die Pipeline unter Pipelines>Releases. Zeigen Sie die Phasenaufgaben in der Phase an, in der Sie Ihren Auftrag hinzufügen möchten. Wählen Sie ... aus, um einen Auftrag hinzuzufügen.

Auftragstypen

Aufträge können unterschiedlich sein, je nachdem, wo sie ausgeführt werden.

YAML

• Agentpoolaufträge werden auf einem Agent in einem Agentpool ausgeführt.
• Serveraufträge werden in der Azure DevOps Server-Instanz ausgeführt.
• Containeraufträge werden in einem Container auf einem Agent in einem Agentpool ausgeführt. Weitere Informationen zum Auswählen von Containern finden Sie unter Definieren von Containeraufträgen.

Klassisch

• Agentpoolaufträge werden auf einem Agent in einem Agentpool ausgeführt.
• Serveraufträge werden in der Azure DevOps Server-Instanz ausgeführt.
• Bereitstellungsgruppenaufträge werden auf Computern in einer Bereitstellungsgruppe ausgeführt. Diese Aufträge sind nur in einer Releasepipeline verfügbar. Weitere Informationen zum Definieren von Gruppen von Zielservern für die Bereitstellung finden Sie unter Bereitstellungsgruppenaufträge.

YAML

• Agentpoolaufträge werden auf einem Agent in einem Agentpool ausgeführt.
• Serveraufträge werden in der Azure DevOps Server-Instanz ausgeführt.

Klassisch

• Agentpoolaufträge werden auf einem Agent in einem Agentpool ausgeführt.
• Serveraufträge werden in der Azure DevOps Server-Instanz ausgeführt.
• Bereitstellungsgruppenaufträge werden auf Computern in einer Bereitstellungsgruppe ausgeführt. Diese Aufträge sind nur in einer Releasepipeline verfügbar.

• Agentpoolaufträge werden auf einem Agent im Agentpool ausgeführt. Diese Aufträge sind in Build- und Releasepipelines verfügbar.
• Serveraufträge werden unter TFS ausgeführt. Diese Aufträge sind in Build- und Releasepipelines verfügbar.
• Bereitstellungsgruppenaufträge werden auf Computern in einer Bereitstellungsgruppe ausgeführt. Diese Aufträge sind nur in Releasepipelines verfügbar.

Agentpoolaufträge

Dies sind die häufigsten Arten von Aufträgen, die auf einem Agent in einem Agent-Pool ausgeführt werden.

• Bei Verwendung Microsoft gehosteter Agents erhält jeder Auftrag in einer Pipeline einen neuen Agent.
• Verwenden Sie Anforderungen mit selbstgehosteten Agents, um anzugeben, welche Funktionen ein Agent zum Ausführen Ihres Auftrags haben muss. Möglicherweise erhalten Sie denselben Agent für aufeinanderfolgende Aufträge, je nachdem, ob in Ihrem Agentpool mehrere Agent vorhanden sind, die den Anforderungen Ihrer Pipeline entsprechen. Wenn in Ihrem Pool nur ein Agent vorhanden ist, der den Anforderungen der Pipeline entspricht, wartet die Pipeline, bis dieser Agent verfügbar ist.

Hinweis

Anforderungen und Funktionen sind für die Verwendung mit selbstgehosteten Agents konzipiert, sodass Aufträge mit einem Agent abgeglichen werden können, der die Anforderungen des Auftrags erfüllt. Wenn Sie Microsoft-gehosteten Agents verwenden, wählen Sie ein Image für den Agent aus, das den Anforderungen des Auftrags entspricht. Obwohl es möglich ist, einem Microsoft gehosteten Agent Funktionen hinzuzufügen, müssen Sie keine Funktionen mit Microsoft gehosteten Agents verwenden.

YAML

pool:
  name: myPrivateAgents    # your job runs on an agent in this pool
  demands: agent.os -equals Windows_NT    # the agent must have this capability to run the job
steps:
- script: echo hello world

Oder mehrere Anforderungen:

pool:
  name: myPrivateAgents
  demands:
  - agent.os -equals Darwin
  - anotherCapability -equals somethingElse
steps:
- script: echo hello world

YAML wird in TFS nicht unterstützt.

Klassisch

Sie haben die Möglichkeit, Anforderungen in der Pipeline, in den Aufträgen oder in beiden anzugeben. Wenn Sie Anforderungen sowohl in der Pipeline als auch in einem Auftrag angeben, ist die Vereinigung der beiden Anforderungssätze erforderlich, damit das System einen Agent auswählen kann.

Erfahren Sie mehr über Agentfunktionen.

Serveraufträge

Aufgaben in einem Serverauftrag werden vom Server (Azure Pipelines oder TFS) orchestriert und auf dem Server ausgeführt. Für einen Serverauftrag ist kein Agent oder keine Zielcomputer erforderlich. Derzeit werden nur wenige Aufgaben in einem Serverauftrag unterstützt.

Unterstützte Aufgaben ohne Agent

Derzeit werden nur die folgenden Aufgaben sofort einsatzbereit für Aufträge ohne Agent unterstützt:

• Verzögerungsaufgabe
• Aufrufen des Azure-Funktionstasks
• Aufrufen der REST-API-Aufgabe
• Manuelle Überprüfungstask
• Aufgabe "Veröffentlichen in Azure Service Bus"
• Aufgabe "Azure Monitor-Warnungen abfragen"
• Task "Arbeitselemente abfragen"

Da Tasks erweiterbar sind, können Sie weitere Aufgaben ohne Agent hinzufügen, indem Sie Erweiterungen verwenden. Das Standardtimeout für Aufträge ohne Agent beträgt 60 Minuten.

YAML

Die vollständige Syntax zum Angeben eines Serverauftrags lautet:

jobs:
- job: string
  timeoutInMinutes: number
  cancelTimeoutInMinutes: number
  strategy:
    maxParallel: number
    matrix: { string: { string: string } }

  pool: server # note: the value 'server' is a reserved keyword which indicates this is an agentless job

Sie können auch die vereinfachte Syntax verwenden:

jobs:
- job: string
  pool: server # note: the value 'server' is a reserved keyword which indicates this is an agentless job

YAML wird in TFS nicht unterstützt.

Klassisch

Sie fügen einen Serverauftrag im Editor hinzu, indem Sie "..." auswählen. im Pipelinekanal auf der Registerkarte Aufgaben einer Pipeline. Die Eigenschaften für den Serverauftrag werden angezeigt, wenn Sie den Auftrag im Editor auswählen.

Abhängigkeiten

Wenn Sie mehrere Aufträge in einer einzelnen Phase definieren, können Sie Abhängigkeiten zwischen ihnen angeben. Pipelines müssen mindestens einen Auftrag ohne Abhängigkeiten enthalten.

Hinweis

Jeder Agent kann jeweils nur einen Auftrag ausführen. Um mehrere Aufträge parallel auszuführen, müssen Sie mehrere Agents konfigurieren. Außerdem benötigen Sie genügend parallele Aufträge.

YAML

Die Syntax zum Definieren mehrerer Aufträge und deren Abhängigkeiten lautet:

jobs:
- job: string
  dependsOn: string
  condition: string

Beispielaufträge, die sequenziell erstellt werden:

jobs:
- job: Debug
  steps:
  - script: echo hello from the Debug build
- job: Release
  dependsOn: Debug
  steps:
  - script: echo hello from the Release build

Beispielaufträge, die parallel erstellt werden (keine Abhängigkeiten):

jobs:
- job: Windows
  pool:
    vmImage: 'windows-latest'
  steps:
  - script: echo hello from Windows
- job: macOS
  pool:
    vmImage: 'macOS-latest'
  steps:
  - script: echo hello from macOS
- job: Linux
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: echo hello from Linux

Beispiel für das Auffächern:

jobs:
- job: InitialJob
  steps:
  - script: echo hello from initial job
- job: SubsequentA
  dependsOn: InitialJob
  steps:
  - script: echo hello from subsequent A
- job: SubsequentB
  dependsOn: InitialJob
  steps:
  - script: echo hello from subsequent B

Beispiel für Einfächern:

jobs:
- job: InitialA
  steps:
  - script: echo hello from initial A
- job: InitialB
  steps:
  - script: echo hello from initial B
- job: Subsequent
  dependsOn:
  - InitialA
  - InitialB
  steps:
  - script: echo hello from subsequent

YAML wird in TFS nicht unterstützt.

Klassisch

Um einen neuen Auftrag hinzuzufügen, wählen Sie "..." aus. im Pipelinekanal auf der Registerkarte Aufgaben der Pipeline. Die Bedingungen und die Reihenfolge der Ausführung für einen Auftrag werden angezeigt, wenn Sie den Auftrag im Editor auswählen.

Wenn Sie mehrere Aufträge in einer Buildpipeline angeben, werden diese standardmäßig parallel ausgeführt. Sie können die Reihenfolge angeben, in der Aufträge ausgeführt werden müssen, indem Sie Abhängigkeiten zwischen Aufträgen konfigurieren. Auftragsabhängigkeiten werden in Releasepipelines nicht unterstützt. Mehrere Aufträge in einer Releasepipeline werden nacheinander ausgeführt.

Mehrere Aufträge, die Sie einem Build oder einer Releasepipeline hinzufügen, werden nacheinander ausgeführt. Sie können die Reihenfolge der Abhängigkeiten zwischen Aufträgen in dieser Version von TFS nicht konfigurieren.

Mehrere Aufträge, die Sie einer Releasepipeline hinzufügen, werden nacheinander ausgeführt. Sie können die Reihenfolge der Abhängigkeiten zwischen Aufträgen in dieser Version von TFS nicht konfigurieren. Sie können Aufträge auch nicht mit Buildpipelines verwenden.

Die unten gezeigte Pipeline unterteilt beispielsweise die gesamte Releaseausführung in separate Ausführungsaufträge, indem zwei Agentaufträge und ein Serverauftrag verwendet werden.

Im obigen Beispiel:

1. Die Aufgaben im ersten Auftrag des Release werden auf einem Agent ausgeführt, und nach Abschluss dieses Auftrags wird der Agent freigegeben.

2. Der Serverauftrag enthält einen Manuellen Eingriffstask, der in Azure Pipelines oder TFS ausgeführt wird. Der Auftrag wird nicht auf einem Agent oder einem Zielserver ausgeführt oder erfordert diese. Der Task "Manueller Eingriff" zeigt seine Meldung an und wartet auf eine "Fortsetzen"- oder "Ablehnen"-Antwort des Benutzers. Wenn in diesem Beispiel das konfigurierte Timeout erreicht wird, lehnt die Aufgabe die Bereitstellung automatisch ab (legen Sie das Timeout im Abschnitt steuerungsoptionen auf Null fest, wenn Sie nicht möchten, dass eine automatisierte Antwort generiert wird).

3. Wenn das Release fortgesetzt wird, werden Aufgaben im dritten Auftrag ausgeführt – möglicherweise auf einem anderen Agent. Wenn das Release abgelehnt wird, wird dieser Auftrag nicht ausgeführt, und das Release wird als fehlerhaft markiert.

Es ist wichtig, einige der Folgen der stufenweisen Ausführung zu verstehen:

• Jeder Auftrag kann unterschiedliche Agents verwenden. Gehen Sie nicht davon aus, dass der Zustand eines früheren Auftrags während nachfolgenden Aufträgen verfügbar ist.

• Die Optionen Fehler fortsetzen und Immer ausführen für Aufgaben in jedem Auftrag haben keine Auswirkungen auf Aufgaben in nachfolgenden Aufträgen. Wenn Sie beispielsweise immer für einen Task am Ende des ersten Auftrags ausführen festlegen , wird nicht garantiert, dass Aufgaben in nachfolgenden Aufträgen ausgeführt werden.

Bedingungen

Sie können die Bedingungen festlegen, unter denen jeder Auftrag ausgeführt wird. Standardmäßig wird ein Auftrag ausgeführt, wenn er nicht von einem anderen Auftrag abhängig ist oder wenn alle Aufträge, von denen er abhängt, abgeschlossen und erfolgreich sind. Sie können dieses Verhalten anpassen, indem Sie die Ausführung eines Auftrags auch dann erzwingen, wenn ein vorheriger Auftrag fehlschlägt, oder indem Sie eine benutzerdefinierte Bedingung angeben.

YAML

Beispiel zum Ausführen eines Auftrags basierend auf dem Status der Ausführung eines vorherigen Auftrags:

jobs:
- job: A
  steps:
  - script: exit 1

- job: B
  dependsOn: A
  condition: failed()
  steps:
  - script: echo this will run when A fails

- job: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')
  steps:
  - script: echo this will run when B runs and succeeds

Beispiel für die Verwendung einer benutzerdefinierten Bedingung:

jobs:
- job: A
  steps:
  - script: echo hello

- job: B
  dependsOn: A
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/master'))
  steps:
  - script: echo this only runs for master

Sie können angeben, dass ein Auftrag basierend auf dem Wert einer Ausgabevariablen ausgeführt wird, die in einem vorherigen Auftrag festgelegt wurde. In diesem Fall können Sie nur Variablen verwenden, die in direkt abhängigen Aufträgen festgelegt sind:

jobs:
- job: A
  steps:
  - script: "echo ##vso[task.setvariable variable=skipsubsequent;isOutput=true]false"
    name: printvar

- job: B
  condition: and(succeeded(), ne(dependencies.A.outputs['printvar.skipsubsequent'], 'true'))
  dependsOn: A
  steps:
  - script: echo hello from B

YAML wird in TFS nicht unterstützt.

Klassisch

Verwenden Sie die Option Diesen Auftrag ausführen für einen Agent- oder Serverauftrag, um die Aufgaben nur auszuführen, wenn bestimmte Bedingungen erfüllt sind. Wählen Sie eine vordefinierte Bedingung aus, oder wählen Sie "Benutzerdefiniert" aus, und geben Sie einen Ausdruck ein, der als true oder false ausgewertet wird. Geschachtelte Ausdrücke können verwendet werden, und die Ausdrücke können auf variablen zugreifen, die in der Releasepipeline verfügbar sind.

Bedingungen werden in dieser Version von TFS nicht unterstützt.

Zeitlimits

Um zu vermeiden, dass Ressourcen in Anspruch genommen werden, wenn Ihr Auftrag nicht reagiert oder zu lange wartet, empfiehlt es sich, ein Limit festzulegen, wie lange Ihr Auftrag ausgeführt werden darf. Verwenden Sie die Einstellung für das Auftragstimeout, um den Grenzwert in Minuten für die Ausführung des Auftrags anzugeben. Das Festlegen des Werts auf 0 bedeutet, dass der Auftrag ausgeführt werden kann:

• Forever für selbstgehostete Agents
• 360 Minuten (6 Stunden) auf Microsoft gehosteten Agents mit einem öffentlichen Projekt und einem öffentlichen Repository
• Für 60 Minuten auf Microsoft gehosteten Agents mit einem privaten Projekt oder privaten Repository (es sei denn, zusätzliche Kapazität wird bezahlt)

Der Timeoutzeitraum beginnt, wenn der Auftrag ausgeführt wird. Die Zeit, zu der sich der Auftrag in der Warteschlange befindet oder auf einen Agent wartet, ist nicht enthalten.

YAML

Ermöglicht timeoutInMinutes das Festlegen eines Grenzwerts für die Ausführungszeit des Auftrags. Wenn nicht angegeben, ist der Standardwert 60 Minuten. Wenn 0 angegeben wird, wird der Höchstwert verwendet (oben beschrieben).

Ermöglicht cancelTimeoutInMinutes es, ein Limit für die Auftragsabbruchzeit festzulegen, wenn der Bereitstellungstask so festgelegt ist, dass er weiterhin ausgeführt wird, wenn ein vorheriger Task fehlgeschlagen ist. Wenn nicht angegeben, ist der Standardwert 5 Minuten. Der Wert sollte zwischen 1 und 35790 Minuten liegen.

jobs:
- job: Test
  timeoutInMinutes: 10 # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: 2 # how much time to give 'run always even if cancelled tasks' before stopping them

YAML wird in TFS nicht unterstützt.

Klassisch

Wählen Sie den Auftrag aus, und geben Sie dann den Timeoutwert an.

Auf der Registerkarte Optionen können Sie Standardwerte für alle Aufträge in der Pipeline angeben. Wenn Sie einen Wert ungleich 0 (null) für das Auftragstimeout angeben, wird jeder Wert überschrieben, der in den Pipelineoptionen angegeben ist. Wenn Sie einen Nullwert angeben, wird der Timeoutwert aus den Pipelineoptionen verwendet. Wenn der Pipelinewert ebenfalls auf 0 (null) festgelegt ist, gibt es kein Timeout.

Aufträge für Microsoft gehostete Agents haben zusätzliche Einschränkungen, wie lange sie ausgeführt werden können.

Sie können das Timeout für jede Aufgabe auch einzeln festlegen. Weitere Informationen finden Sie unter Aufgabensteuerungsoptionen.

Konfiguration mit mehreren Aufträgen

Aus einem einzelnen Auftrag, den Sie erstellen, können Sie mehrere Aufträge auf mehreren Agents parallel ausführen. Beispiele hierfür sind:

• Builds mit mehreren Konfigurationen: Sie können mehrere Konfigurationen parallel erstellen. Sie können beispielsweise eine Visual C++-App für sowohl release als auch debug für Konfigurationen auf und x64x86 plattformen erstellen. Weitere Informationen finden Sie unter Visual Studio-Build – mehrere Konfigurationen für mehrere Plattformen.

• Bereitstellungen mit mehreren Konfigurationen: Sie können mehrere Bereitstellungen parallel ausführen, z. B. in verschiedenen geografischen Regionen.

• Multikonfigurationstests: Sie können mehrere Konfigurationen parallel testen.

• Die Mehrfachkonfiguration generiert immer mindestens einen Auftrag, auch wenn eine Variable mit mehreren Konfigurationen leer ist.

YAML

Die matrix Strategie ermöglicht es, einen Auftrag mehrmals mit unterschiedlichen Variablensätzen zu versenden. Das maxParallel -Tag schränkt den Umfang der Parallelität ein. Der folgende Auftrag wird dreimal mit den werten Standort und Browser wie angegeben verteilt. Es werden jedoch nur zwei Aufträge gleichzeitig ausgeführt.

jobs:
- job: Test
  strategy:
    maxParallel: 2
    matrix: 
      US_IE:
        Location: US
        Browser: IE
      US_Chrome:
        Location: US
        Browser: Chrome
      Europe_Chrome:
        Location: Europe
        Browser: Chrome

Hinweis

Matrixkonfigurationsnamen (wie US_IE oben) dürfen nur grundlegende lateinische Alphabetbuchstaben (A-Z, a-z), Zahlen und Unterstriche (_) enthalten. Der Name muss mit einem Buchstaben beginnen. Außerdem müssen sie maximal 100 Zeichen lang sein.

Es ist auch möglich, Ausgabevariablen zum Generieren einer Matrix zu verwenden. Dies kann hilfreich sein, wenn Sie die Matrix mithilfe eines Skripts generieren müssen.

matrix akzeptiert einen Laufzeitausdruck, der ein zeichenfolgenifiziertes JSON-Objekt enthält. Dieses JSON-Objekt muss, wenn es erweitert wird, mit der Matrixsyntax übereinstimmen. Im folgenden Beispiel haben wir die JSON-Zeichenfolge hartcodiert, aber sie könnte von einer Skriptsprache oder einem Befehlszeilenprogramm generiert werden.

jobs:
- job: generator
  steps:
  - bash: echo "##vso[task.setVariable variable=legs;isOutput=true]{'a':{'myvar':'A'}, 'b':{'myvar':'B'}}"
    name: mtrx
  # This expands to the matrix
  #   a:
  #     myvar: A
  #   b:
  #     myvar: B
- job: runner
  dependsOn: generator
  strategy:
    matrix: $[ dependencies.generator.outputs['mtrx.legs'] ]
  steps:
  - script: echo $(myvar) # echos A or B depending on which leg is running

YAML wird in TFS nicht unterstützt.

Klassisch

Um mehrere Aufträge mit der Multikonfigurationsoption auszuführen, identifizieren Sie eine Variable mit dem Namen Multiplikator und geben eine Liste von Werten für diesen Multiplikator an. Für jeden Wert in der Liste wird ein separater Auftrag ausgeführt. Um Multiplikatoren für Build oder Bereitstellung verwenden zu können, müssen Sie Folgendes ausführen:

• Definieren Sie mindestens eine Variablen auf der Registerkarte Variablen der Pipeline oder in einer Variablengruppe. Jede Variable, die in diesem Kontext als Multiplikatorvariable bezeichnet wird, muss als durch Trennzeichen getrennte Liste der Werte definiert werden, die Einzeln an die Agents übergeben werden sollen.

• Geben Sie den Namen der Multiplikatorvariablen ohne die $ Klammern und als Wert des Multiplikatorparameters ein . Die Verwendung einer geheimen Variablen als Multiplikatorvariable wird nicht unterstützt.

• Wenn Sie den Auftrag für mehr als eine Multiplikatorvariable ausführen möchten, geben Sie die Variablennamen als durch Trennzeichen getrennte Liste ein, wobei sie die $ Klammern und für jeden wert weglassen.

• Wenn Sie die Anzahl der während der Bereitstellung verwendeten Agents auf eine Zahl beschränken möchten, die kleiner ist als für Ihr Abonnement konfiguriert, geben Sie diesen Wert als Parameter Maximale Anzahl von Agents ein .

Sie können beispielsweise zwei Variablen namens Location und Browser wie folgt definieren:

• Lage = US,Europe
• Browser = IE,Chrome,Edge,Firefox

Die folgende Konfiguration führt die Bereitstellung achtMal mit maximal vier Agents gleichzeitig aus:

• Multiplikatoren = Location,Browser
• Maximale Anzahl von Agents = 4

Mit Multikonfiguration können Sie mehrere Aufträge ausführen, die jeweils einen anderen Wert für eine oder mehrere Variablen (Multiplikatoren) aufweisen. Wenn Sie denselben Auftrag für mehrere Agents ausführen möchten, können Sie die Option Parallelität mit mehreren Agents verwenden. Das obige Beispiel für das Testslicing kann über eine Option mit mehreren Agents ausgeführt werden.

Aufteilen

Ein Agentauftrag kann verwendet werden, um eine Reihe von Tests parallel auszuführen. Beispielsweise können Sie eine große Suite mit 1.000 Tests auf einem einzelnen Agent ausführen. Alternativ können Sie zwei Agents verwenden und jeweils 500 Tests parallel ausführen.

Um das Schneiden zu nutzen, sollten die Aufgaben im Auftrag intelligent genug sein, um den Slice zu verstehen, zu dem sie gehören.

Der Visual Studio-Testtask ist eine solche Aufgabe, die testslicing unterstützt. Wenn Sie mehrere Agents installiert haben, können Sie angeben, wie der Visual Studio-Testtask auf diesen Agents parallel ausgeführt wird.

YAML

Mit parallel der Strategie kann ein Auftrag mehrfach dupliziert werden. Variablen System.JobPositionInPhase und System.TotalJobsInPhase werden jedem Auftrag hinzugefügt. Die Variablen können dann in Ihren Skripts verwendet werden, um die Arbeit auf die Aufträge aufzuteilen. Weitere Informationen finden Sie unter Parallele und mehrfache Ausführung mithilfe von Agentaufträgen.

Der folgende Auftrag wird fünfmal mit den Werten von System.JobPositionInPhaseSystem.TotalJobsInPhase und entsprechend festgelegt.

jobs:
- job: Test
  strategy:
    parallel: 5

YAML wird in TFS nicht unterstützt.

Klassisch

Geben Sie die Multi-Agent-Option für einen Agentauftrag an, um das Slicing zu nutzen. Der Auftrag wird so oft wie die Anzahl der von Ihnen angegebenen Agents und die Variablen System.JobPositionInPhase verteilt und System.TotalJobsInPhase automatisch in jedem Auftrag festgelegt.

Auftragsvariablen

Wenn Sie YAML verwenden, können Variablen für den Auftrag angegeben werden. Die Variablen können mithilfe der Makrosyntax $(variableName) an Aufgabeneingaben übergeben oder in einem Skript mithilfe der Stufenvariablen zugegriffen werden.

YAML

Hier sehen Sie ein Beispiel für das Definieren von Variablen in einem Auftrag und deren Verwendung in Aufgaben.

variables:
  mySimpleVar: simple var value
  "my.dotted.var": dotted var value
  "my var with spaces": var with spaces value

steps:
- script: echo Input macro = $(mySimpleVar). Env var = %MYSIMPLEVAR%
  condition: eq(variables['agent.os'], 'Windows_NT')
- script: echo Input macro = $(mySimpleVar). Env var = $MYSIMPLEVAR
  condition: in(variables['agent.os'], 'Darwin', 'Linux')
- bash: echo Input macro = $(my.dotted.var). Env var = $MY_DOTTED_VAR
- powershell: Write-Host "Input macro = $(my var with spaces). Env var = $env:MY_VAR_WITH_SPACES"

YAML wird in TFS nicht unterstützt.

Klassisch

Auftragsvariablen werden im Web-Editor noch nicht unterstützt.

Informationen zur Verwendung einer Bedingung finden Sie unter Angeben von Bedingungen.

Arbeitsbereich

Wenn Sie einen Agentpoolauftrag ausführen, wird ein Arbeitsbereich für den Agent erstellt. Der Arbeitsbereich ist ein Verzeichnis, in dem er die Quelle herunterlädt, Schritte ausführt und Ausgaben erzeugt. Auf das Arbeitsbereichsverzeichnis kann in Ihrem Auftrag mithilfe einer Pipeline.Workspace Variablen verwiesen werden. Dabei werden verschiedene Unterverzeichnisse erstellt:

Wenn Sie einen Agentpoolauftrag ausführen, wird ein Arbeitsbereich für den Agent erstellt. Der Arbeitsbereich ist ein Verzeichnis, in dem er die Quelle herunterlädt, Schritte ausführt und Ausgaben erzeugt. Auf das Arbeitsbereichsverzeichnis kann in Ihrem Auftrag mithilfe einer Agent.BuildDirectory Variablen verwiesen werden. Dabei werden verschiedene Unterverzeichnisse erstellt:

• Build.SourcesDirectory ist der Ort, an dem Aufgaben den Quellcode der Anwendung herunterladen.
• Build.ArtifactStagingDirectory ist der Ort, an dem Aufgaben Artefakte herunterladen, die für die Pipeline erforderlich sind, oder Artefakte hochladen, bevor sie veröffentlicht werden.
• Build.BinariesDirectory ist der Ort, an dem Aufgaben ihre Ausgaben schreiben.
• Common.TestResultsDirectory ist der Ort, an dem Aufgaben ihre Testergebnisse hochladen.

YAML

Die $(Build.ArtifactStagingDirectory) und $(Common.TestResultsDirectory) werden vor jedem Build immer gelöscht und neu erstellt.

Wenn Sie eine Pipeline auf einem selbstgehosteten Agent ausführen, wird standardmäßig keines der Anderen Unterverzeichnisse als $(Build.ArtifactStagingDirectory) und $(Common.TestResultsDirectory) zwischen zwei aufeinanderfolgenden Ausführungen bereinigt. Daher können Sie inkrementelle Builds und Bereitstellungen durchführen, sofern Aufgaben implementiert werden, um dies zu nutzen. Sie können dieses Verhalten überschreiben, indem Sie die workspace Einstellung für den Auftrag verwenden.

Wichtig

Die Optionen für die Bereinigung des Arbeitsbereichs gelten nur für selbstgehostete Agents. Bei Verwendung Microsoft gehosteter Agents werden Aufträge immer für einen neuen Agent ausgeführt.

- job: myJob
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Wenn Sie eine der clean Optionen angeben, werden sie wie folgt interpretiert:

• outputs: Löschen Sie Build.BinariesDirectory , bevor Sie einen neuen Auftrag ausführen.
• resources: Löschen Sie Build.SourcesDirectory , bevor Sie einen neuen Auftrag ausführen.
• all: Löschen Sie das gesamte Pipeline.Workspace Verzeichnis, bevor Sie einen neuen Auftrag ausführen.

  jobs:
  - deployment: MyDeploy
    pool:
      vmImage: 'ubuntu-latest'
    workspace:
      clean: all
    environment: staging

Hinweis

Je nach Ihren Agentfunktionen und Pipelineanforderungen kann jeder Auftrag an einen anderen Agent in Ihrem selbstgehosteten Pool weitergeleitet werden. Daher erhalten Sie möglicherweise einen neuen Agent für nachfolgende Pipelineausführungen (oder Phasen oder Aufträge in derselben Pipeline), sodass die Nichtbereinigung keine Garantie dafür ist, dass nachfolgende Ausführungen, Aufträge oder Phasen auf Ausgaben früherer Ausführungen, Aufträge oder Phasen zugreifen können. Sie können agent-Funktionen und Pipelineanforderungen konfigurieren, um anzugeben, welche Agents zum Ausführen eines Pipelineauftrags verwendet werden. Es gibt jedoch keine Garantie, dass nachfolgende Aufträge denselben Agent wie vorherige Aufträge verwenden, sofern sich nicht nur ein einzelner Agent im Pool befindet, der die Anforderungen erfüllt. Weitere Informationen finden Sie unter Angeben von Anforderungen.

Zusätzlich zur Bereinigung des Arbeitsbereichs können Sie auch die Bereinigung konfigurieren, indem Sie die Einstellung Bereinigen in der Benutzeroberfläche der Pipelineeinstellungen konfigurieren. Wenn die Einstellung Bereinigentrue ist, was auch ihr Standardwert ist, entspricht sie der Angabe clean: true für jeden Auscheckschritt in Ihrer Pipeline. Wenn Sie angeben clean: true, werden Sie gefolgt von ausgeführt git clean -ffdx , git reset --hard HEAD bevor Git abgerufen wird. So konfigurieren Sie die Einstellung Bereinigen :

1. Bearbeiten Sie Ihre Pipeline, wählen Sie ..., und wählen Sie Trigger aus.

   

2. Wählen Sie YAML, Quellen abrufen aus, und konfigurieren Sie die gewünschte Einstellung Bereinigen . Der Standardwert ist true.

   

YAML wird in TFS nicht unterstützt.

Klassisch

Wenn Sie eine Pipeline auf einem selbstgehosteten Agent ausführen, wird standardmäßig keines der Unterverzeichnisse zwischen zwei aufeinanderfolgenden Ausführungen bereinigt. Daher können Sie inkrementelle Builds und Bereitstellungen ausführen, sofern hierfür Aufgaben implementiert werden. Sie können dieses Verhalten jedoch überschreiben, indem Sie die Clean build Option unter Get sources Task verwenden. Die Optionen variieren je nach Typ des verwendeten Repositorys.

• GitHub
• Azure Repos (Git)
• TFVC

Artefakt-Download

Diese YAML-Beispieldatei veröffentlicht das Artefakt WebSite und lädt das Artefakt dann in herunter $(Pipeline.Workspace). Der Auftrag Bereitstellen wird nur ausgeführt, wenn der Buildauftrag erfolgreich ist.

YAML

# test and upload my code as an artifact named WebSite
jobs:
- job: Build
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: npm test
  - task: PublishBuildArtifacts@1
    inputs:
      pathtoPublish: '$(System.DefaultWorkingDirectory)'
      artifactName: WebSite

# download the artifact and deploy it only if the build job succeeded
- job: Deploy
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - checkout: none #skip checking out the default repository resource
  - task: DownloadBuildArtifacts@0
    displayName: 'Download Build Artifacts'
    inputs:
      artifactName: WebSite
      downloadPath: $(System.DefaultWorkingDirectory)

  dependsOn: Build
  condition: succeeded()

YAML wird in TFS nicht unterstützt.

Klassisch

In einer Releasepipeline können Sie den Download von Artefakten während der Auftragsausführung überspringen. Verwenden Sie diese Option, wenn Sie Ihre eigene benutzerdefinierte Logik zum Herunterladen von Artefakten mithilfe von Aufgaben implementieren möchten oder wenn die Aufgaben in einem bestimmten Auftrag nicht auf den Artefakten basieren.

Alternativ können Sie bestimmte Artefakte während der Auftragsausführung in einem Release herunterladen. Verwenden Sie diese Option, wenn die Aufgaben in einem bestimmten Auftrag nur bestimmte Artefakte verwenden.

Informationen zur Verwendung von dependsOn und condition finden Sie unter Angeben von Bedingungen.

Zugriff auf OAuth-Token

Sie können Skripts, die in einem Auftrag ausgeführt werden, erlauben, auf das aktuelle Azure Pipelines- oder TFS OAuth-Sicherheitstoken zuzugreifen. Das Token kann zur Authentifizierung bei der Azure Pipelines-REST-API verwendet werden.

YAML

Das OAuth-Token ist für YAML-Pipelines immer verfügbar. Sie muss explizit der Aufgabe oder dem Schritt zugeordnet werden, indem verwendet envwird. Hier siehst du ein Beispiel:

steps:
- powershell: |
    $url = "$($env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI)$env:SYSTEM_TEAMPROJECTID/_apis/build/definitions/$($env:SYSTEM_DEFINITIONID)?api-version=4.1-preview"
    Write-Host "URL: $url"
    $pipeline = Invoke-RestMethod -Uri $url -Headers @{
      Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
    }
    Write-Host "Pipeline = $($pipeline | ConvertTo-Json -Depth 100)"
  env:
    SYSTEM_ACCESSTOKEN: $(system.accesstoken)

YAML wird in TFS nicht unterstützt.

Klassisch

Wählen Sie in den Steuerungsoptionen für den Auftrag die Option Skripts zugriff auf OAuth-Token zulassen aus. Das Token ist als Umgebungsvariable SYSTEM_ACCESSTOKENverfügbar.

Nächste Schritte

• Bereitstellungsgruppenaufträge
• Bedingungen