Angeben von Aufträgen in Ihrer Pipeline

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

Sie können Ihre Pipeline nach Aufträgen organisieren. Jede Pipeline umfasst mindestens einen Auftrag. Ein Auftrag besteht aus einer Reihe von Schritten, die nacheinander als eine Einheit ausgeführt werden. Anders ausgedrückt: Ein Auftrag ist die kleinste Arbeitseinheit, die zur Ausführung geplant werden kann.

Informationen zu den wichtigsten Konzepten und Komponenten, aus denen eine Pipeline besteht, finden Sie unter Schlüsselkonzepte für neue Azure Pipelines-Benutzer.

Azure Pipelines unterstützt keine Auftragspriorität für YAML-Pipelines. Um zu steuern, wann Aufträge ausgeführt werden, können Sie Bedingungen und Abhängigkeiten angeben.

Definieren eines einzelnen Auftrags

YAML

Im einfachsten Fall umfasst eine Pipeline einen einzelnen Auftrag. In diesem Fall müssen Sie das job Schlüsselwort nicht ausdrücklich 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 von Microsoft gehosteten Agent ausgeführt wird und Hello world ausgibt.

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

Möglicherweise möchten Sie zusätzliche Eigenschaften für diesen Auftrag angeben. Dazu können Sie das job-Schlüsselwort verwenden.

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

Ihre Pipeline umfassen möglicherweise 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 Stages mit jeweils mehreren Aufträgen umfassen. 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 wie folgt:

- 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 der Hauptzweck Ihres Auftrags darin besteht, Ihre App bereitzustellen (im Gegensatz zum Erstellen oder Testen Ihrer App), dann können Sie einen speziellen Auftragstyp namens Bereitstellungsauftrag verwenden.

Die Syntax für einen Bereitstellungsauftrag lautet wie folgt:

- 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 job hinzufügen können, empfehlen wir, stattdessen einen Bereitstellungsauftrag zu verwenden. Ein Bereitstellungsauftrag bietet verschiedene Vorteile. Sie können die Bereitstellung beispielsweise in einer Umgebung vornehmen. Dies hat den Vorteil, dass Sie den Verlauf der durchgeführten Bereitstellung anzeigen können.

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 Aufgaben in der Stage an, in der Sie Ihren Auftrag hinzufügen möchten. Wählen Sie ... aus, um einen Auftrag hinzuzufügen.

Auftragstypen

Es gibt verschiedene Auftragstypen, 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 Zielservergruppen für die Bereitstellung finden Sie unter Bereitstellungsgruppenaufträge.

Agentpoolaufträge

Dies ist der häufigste Auftragstyp, der auf einem Agent in einem Agentpool ausgeführt wird.

• Wenn Sie von Microsoft gehostete Agents verwenden, wird für jeden Auftrag in einer Pipeline ein neuer Agent bereitgestellt.
• Geben Sie mithilfe von Anforderungen für selbstgehostete Agents an, über welche Funktionen ein Agent verfügen muss, um Ihren Auftrag auszuführen. Möglicherweise wird Ihnen für aufeinanderfolgende Aufträge derselbe Agent zugeteilt. Dies hängt davon ab, ob in Ihrem Agentpool mehrere Agents 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, damit Aufträge einem Agent zugewiesen werden können, der die Anforderungen des Auftrags erfüllt. Wenn Sie von Microsoft gehostete Agents verwenden, wählen Sie ein Image für den Agent aus, das den Anforderungen des Auftrags entspricht. Obwohl es möglich ist, einem von Microsoft gehosteten Agent Funktionen hinzuzufügen, müssen Sie bei von Microsoft gehosteten Agents keine Funktionen 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

Klassisch

Sie können Anforderungen in der Pipeline, in den Aufträgen oder in beidem angeben. Wenn Sie sowohl in der Pipeline als auch in einem Auftrag Anforderungen angeben, müssen die beiden Anforderungssätze kombiniert werden, damit das System einen Agent auswählen kann.

Erfahren Sie mehr über Agentfunktionen.

Serveraufträge

Die Aufgaben in einem Serverauftrag werden vom Server (Azure Pipelines oder TFS) orchestriert und auf diesem ausgeführt. Für einen Serverauftrag sind weder ein Agent noch Zielcomputer erforderlich. Derzeit werden nur einige wenige Aufgaben in einem Serverauftrag unterstützt. Die maximale Zeit für einen Serverauftrag beträgt 30 Tage.

Unterstützte Aufgaben für Aufträge ohne Agent

Derzeit werden für Aufträge ohne Agent standardmäßig nur die folgenden Aufgaben unterstützt:

• Verzögerungsaufgabe
• Aufgabe „Azure-Funktion aufrufen“
• Aufgabe „REST-API aufrufen“
• Aufgabe „Manuelle Validierung“
• Aufgabe „In Azure Service Bus veröffentlichen“
• Aufgabe „Azure Monitor-Warnungen abfragen“
• Aufgabe „Arbeitselemente abfragen“

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

YAML

Die vollständige Syntax zum Angeben eines Serverauftrags lautet wie folgt:

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

Klassisch

Sie fügen einen Serverauftrag im Editor hinzu, indem Sie auf der Registerkarte Aufgaben einer Pipeline im Kanal Pipeline die Option „...“ auswählen. 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 einzigen Stage definieren, können Sie Abhängigkeiten zwischen diesen Aufträgen festlegen. Pipelines müssen mindestens einen Auftrag ohne Abhängigkeiten enthalten. Standardmäßig werden Azure DevOps-YAML-Pipelineaufträge parallel ausgeführt – es sei denn, der Wert dependsOn ist festgelegt.

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 müssen genügend Parallelaufträge vorhanden sein.

YAML

Die Syntax zum Definieren mehrerer Aufträge und ihrer Abhängigkeiten lautet wie folgt:

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 nach außen:

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 das Auffächern nach innen:

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

Klassisch

Um einen neuen Auftrag hinzuzufügen, wählen Sie auf der Registerkarte Aufgaben der Pipeline im Pipelinekanal die Option „...“ aus. 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 festlegen, 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. In einer Releasepipeline werden mehrere Aufträge nacheinander ausgeführt.

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

Auf das obige Beispiel trifft Folgendes zu:

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

2. Der Serverauftrag enthält eine Aufgabe „Manueller Eingriff“, die in Azure Pipelines oder TFS ausgeführt wird. Der Auftrag wird weder auf einem Agent noch auf einem Zielserver ausgeführt und benötigt diese auch nicht. Die Aufgabe „Manueller Eingriff“ zeigt die entsprechende Meldung an und wartet auf die Benutzerrückmeldung „Fortfahren“ oder „Ablehnen“. In diesem Beispiel wird die Bereitstellung automatisch durch die Aufgabe abgelehnt, wenn das konfigurierte Timeout erreicht ist (legen Sie das Timeout im Abschnitt mit den Steuerungsoptionen auf 0 fest, wenn keine automatische Antwort generiert werden soll).

3. Wenn das Release fortgesetzt wird, werden die 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 Konsequenzen einer Ausführung in Phasen zu verstehen:

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

• Die Optionen Bei Fehler fortsetzen und Immer ausführen für Aufgaben in jedem Auftrag haben keine Auswirkungen auf Aufgaben in nachfolgenden Aufträgen. Wenn Sie beispielsweise für eine Aufgabe am Ende des ersten Auftrags die Einstellung Immer ausführen festlegen, garantiert dies nicht, dass die Aufgaben der nachfolgenden Aufträge 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 von keinem anderen Auftrag abhängt oder wenn alle Aufträge, von denen er abhängt, abgeschlossen wurden und erfolgreich waren. Sie können dieses Verhalten anpassen, indem Sie die Ausführung eines Auftrags erzwingen, auch wenn ein vorheriger Auftrag fehlschlägt, oder indem Sie eine benutzerdefinierte Bedingung angeben.

YAML

Beispiel für die Ausführung 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/main'))
  steps:
  - script: echo this only runs for master

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

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

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 klicken Sie auf „Benutzerdefiniert“, und geben Sie einen Ausdruck ein, der als true oder false ausgewertet wird. Sie können geschachtelte Ausdrücke verwenden, und die Ausdrücke können auf Variablen zugreifen, die in der Releasepipeline verfügbar sind.

Zeitlimits

Damit keine Ressourcen verbraucht werden, wenn Ihr Auftrag nicht reagiert oder zu lange wartet, empfiehlt es sich, ein Limit für die Ausführungsdauer Ihres Auftrags festzulegen. Verwenden Sie die Timeouteinstellung für den Auftrag, um ein Limit in Minuten für die Auftragsausführung festzulegen. Wenn Sie den Wert auf 0 festlegen, bedeutet dies, dass der Auftrag folgendermaßen ausgeführt werden kann:

• Ohne Zeitlimit auf selbstgehosteten Agents
• Für 360 Minuten (6 Stunden) auf von Microsoft gehosteten Agents mit einem öffentlichen Projekt und einem öffentlichen Repository
• Für 60 Minuten auf von Microsoft gehosteten Agents mit einem privaten Projekt oder privaten Repository (sofern keine zusätzliche Kapazität erworben wird)

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

YAML

Mit timeoutInMinutes können Sie ein Limit für die Ausführungsdauer des Auftrags festlegen. Sofern nicht angegeben, beträgt der Standardwert 60 Minuten. Wenn Sie 0 angeben, wird die Höchstgrenze verwendet (wie oben beschrieben).

Mit cancelTimeoutInMinutes können Sie einen Grenzwert für die Abbruchzeit des Auftrags festlegen, wenn die Bereitstellungsaufgabe so konfiguriert ist, dass sie auch nach dem Fehlschlagen einer vorherigen Aufgabe weiter ausgeführt wird. Sofern nicht angegeben, beträgt 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

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 Null als Timeout für den Auftrag angeben, hat dieser Vorrang vor allen Werten, die in den Pipelineoptionen angegeben sind. Wenn Sie den Wert 0 angeben, wird der Timeoutwert aus den Pipelineoptionen verwendet. Wenn der Pipelinewert ebenfalls auf Null festgelegt ist, gibt es kein Timeout.

Timeouts haben die folgende Rangebene.

1. Bei von Microsoft gehosteten Agents sind Aufträge begrenzt, wie lange sie basierend auf dem Projekttyp ausgeführt werden können und ob sie mit einem kostenpflichtigen parallelen Auftrag ausgeführt werden. Wenn das von Microsoft gehostete Auftragstimeoutintervall verstrichen ist, wird der Auftrag beendet. In von Microsoft gehosteten Agents können Aufträge nicht länger als dieses Intervall ausgeführt werden, unabhängig von Zeitüberschreitungen auf Auftragsebene, die im Auftrag angegeben sind.
2. Das auf Auftragsebene konfigurierte Timeout gibt die maximale Dauer des auszuführenden Auftrags an. Wenn das Zeitüberschreitungsintervall der Auftragsebene verstrichen ist, wird der Auftrag beendet. Wenn der Auftrag auf einem von Microsoft gehosteten Agent ausgeführt wird, hat das Festlegen des Zeitlimits für die Auftragsebene auf ein Intervall größer als das in Microsoft gehostete Zeitlimit für die Auftragsebene keine Auswirkung, und das von Microsoft gehostete Zeitlimit wird verwendet.
3. Sie können das Timeout für jede Aufgabe auch einzeln festlegen. Weitere Informationen finden Sie unter Aufgabensteuerungsoptionen. Wenn das Zeitüberschreitungsintervall auf Auftragsebene vor Abschluss der Aufgabe verstrichen ist, wird der ausgeführte Auftrag beendet, auch wenn der Vorgang mit einem längeren Timeoutintervall konfiguriert ist.

Konfiguration mit mehreren Aufträgen

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

• Builds mit mehreren Konfigurationen: Sie können mehrere Konfigurationen parallel erstellen. Sie könnten zum Beispiel eine Visual C++-App sowohl für debug- als auch für release-Konfigurationen auf den Plattformen x86 und x64 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.

• Tests mit mehreren Konfigurationen: Sie können mehrere Konfigurationen parallel testen.

• Bei Verwendung mehrerer Konfigurationen wird immer mindestens ein Auftrag generiert, selbst wenn eine Variable für mehrere Konfigurationen leer ist.

YAML

Die matrix-Strategie ermöglicht es, einen Auftrag mehrmals mit unterschiedlichen Variablensätzen zu senden. Das Tag maxParallel schränkt den Umfang der Parallelität ein. Der folgende Auftrag wird dreimal mit den angegebenen Werten für Standort und Browser gesendet. Es werden jedoch jeweils 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

Namen von Matrixkonfigurationen (wie US_IE oben) dürfen nur Buchstaben des lateinischen Alphabets (A–Z, a–z), Ziffern und Unterstriche enthalten (_). Der Name muss mit einem Buchstaben beginnen. Außerdem darf der Name höchstens 100 Zeichen umfassen.

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

matrix akzeptiert einen Laufzeitausdruck, der ein als Zeichenfolge dargestelltes JSON-Objekt enthält. Dieses JSON-Objekt muss bei Erweiterung mit der Matrixsyntax übereinstimmen. Im folgenden Beispiel wurde die JSON-Zeichenfolge hartcodiert, aber sie könnte auch durch eine Skriptsprache oder ein 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

Klassisch

Wenn Sie mehrere Aufträge mit der Option „Multikonfiguration“ ausführen möchten, legen Sie eine Variable namens Multiplier fest und geben eine Liste mit Werten für diesen Multiplikator an. Für jeden Wert in der Liste wird ein separater Auftrag ausgeführt. Um Multiplikatoren für einen Build oder eine Bereitstellung zu verwenden, müssen Sie Folgendes tun:

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

• Geben Sie den Namen der Multiplikatorvariablen (ohne $ und Klammern) 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 Komma getrennte Liste ein, wobei Sie $ und die Klammern für jede Variable weglassen.

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

Sie könnten zum Beispiel zwei Variablen namens Location und Browser wie folgt definieren:

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

Bei der folgenden Konfiguration wird die Bereitstellung achtmal mit maximal vier Agents gleichzeitig ausgeführt:

• Multipliers = Location,Browser
• Maximum number of agents = 4

Mit der Multikonfiguration können Sie mehrere Aufträge ausführen, wobei jeder einen anderen Wert für eine oder mehrere Variablen (Multiplikatoren) aufweist. Wenn Sie denselben Auftrag auf mehreren Agents ausführen möchten, können Sie die Parallelitätsoption mit Multi-Agents verwenden. Das obige Beispiel für das Aufteilen von Tests kann über die Option „Multi-Agent“ umgesetzt werden.

Aufteilen

Mit einem Agentauftrag können Sie eine Reihe von Tests parallel durchführen. Sie können zum Beispiel eine große Sammlung von 1.000 Tests auf einem einzigen Agent ausführen. Alternativ können Sie zwei Agents verwenden und auf jedem von ihnen 500 Tests parallel ausführen.

Damit Sie die Aufteilung nutzen können, müssen die Aufgaben im Auftrag wissen, welchem Segment sie angehören.

Die Visual Studio-Testaufgabe ist eine solche Aufgabe, die die Aufteilung von Tests unterstützt. Wenn Sie mehrere Agents installiert haben, können Sie angeben, wie die Visual Studio-Testaufgabe parallel auf diesen Agents ausgeführt werden soll.

YAML

Die parallel-Strategie ermöglicht es, einen Auftrag mehrmals zu duplizieren. Die Variablen System.JobPositionInPhase und System.TotalJobsInPhase werden jedem Auftrag hinzugefügt. Anschließend können die Variablen in Ihren Skripts verwendet werden, um die Arbeit auf die einzelnen Aufträge zu verteilen. Weitere Informationen finden Sie unter Parallele und mehrfache Ausführung mithilfe von Agentaufträgen.

Der folgende Auftrag wird mit entsprechender Festlegung der Werte von System.JobPositionInPhase und System.TotalJobsInPhase fünfmal gesendet.

jobs:
- job: Test
  strategy:
    parallel: 5

Klassisch

Geben Sie die Option Multi-Agent für einen Agentauftrag an, um die Aufteilung zu nutzen. Der Auftrag wird entsprechend der von Ihnen angegebenen Anzahl von Agents gesendet, und die Variablen System.JobPositionInPhase und System.TotalJobsInPhase werden in jedem Auftrag automatisch festgelegt.

Auftragsvariablen

Wenn Sie YAML verwenden, können Variablen für den Auftrag angegeben werden. Die Variablen können mit der Makrosyntax $(Variablenname) an Aufgabeneingaben übergeben werden oder innerhalb eines Skripts mithilfe der Stagevariablen aufgerufen werden.

YAML

Das folgende Beispiel zeigt, wie Sie Variablen in einem Auftrag definieren und sie in Aufgaben verwenden.

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"

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 das der Quellcode heruntergeladen wird, in dem Schritte ausgeführt und Ausgaben erzeugt werden. Das Verzeichnis für den Arbeitsbereich kann in Ihrem Auftrag über die Variable Pipeline.Workspace referenziert werden. In diesem werden verschiedene Unterverzeichnisse erstellt:

• Build.SourcesDirectory: In dieses Unterverzeichnis laden Aufgaben den Quellcode der Anwendung herunter.
• Build.ArtifactStagingDirectory ist wo Aufgaben Artefakte herunterladen, die für die Pipeline benötigt werden oder Artefakte uploaden bevor sie veröffentlicht werden.
• Build.BinariesDirectory: In dieses Unterverzeichnis schreiben Aufgaben ihre Ausgaben.
• Common.TestResultsDirectory: In dieses Unterverzeichnis laden Aufgaben ihre Testergebnisse hoch.

YAML

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

Wenn Sie eine Pipeline auf einem selbstgehosteten Agent ausführen, wird zwischen zwei aufeinanderfolgenden Ausführungen standardmäßig (mit Ausnahme von $(Build.ArtifactStagingDirectory) und $(Common.TestResultsDirectory)) keines der Unterverzeichnisse bereinigt. Dadurch können Sie inkrementelle Builds und Bereitstellungen durchführen, sofern Aufgaben implementiert sind, die diese Möglichkeit nutzen. Sie können dieses Verhalten überschreiben, indem Sie die Einstellung workspace für den Auftrag verwenden.

Wichtig

Die Optionen zum Bereinigen des Arbeitsbereichs gelten nur für selbstgehostete Agents. Wenn Sie von Microsoft gehostete Agents verwenden, werden Aufträge immer auf einem 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 diese wie folgt interpretiert:

• outputs: Löschung von Build.BinariesDirectory vor dem Ausführen eines neuen Auftrags
• resources: Löschung von Build.SourcesDirectory vor dem Ausführen eines neuen Auftrags
• all: Löschung des gesamten Verzeichnisses Pipeline.Workspace vor dem Ausführen eines neuen Auftrags

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

Hinweis

Abhängig von den Funktionen Ihres Agents und den Anforderungen der Pipeline kann jeder Auftrag an einen anderen Agent in Ihrem selbstgehosteten Pool weitergeleitet werden. Infolgedessen wird für nachfolgende Pipelineausführungen (oder Stages oder Aufträge in derselben Pipeline) möglicherweise ein neuer Agent abgerufen. Keine Bereinigung ist also keine Garantie dafür, dass nachfolgende Ausführungen, Aufträge oder Phasen auf die Ausgaben vorheriger Ausführungen, Aufträge oder Stages zugreifen können. Sie können Agentfunktionen und Pipelineanforderungen konfigurieren, um festzulegen, welche Agents für die Ausführung eines Pipelineauftrags verwendet werden. Sofern sich jedoch nicht nur ein einziger Agent im Pool befindet, der die Anforderungen erfüllt, gibt es keine Garantie dafür, dass nachfolgende Aufträge denselben Agent verwenden wie vorherige Aufträge. Weitere Informationen finden Sie unter Angeben von Anforderungen.

Zusätzlich zur Arbeitsbereichbereinigung können Sie die Bereinigung auch über die Einstellung Bereinigung in der Benutzeroberfläche der Pipelineeinstellungen konfigurieren. Wenn die Einstellung Bereinigen auf true festgelegt ist, dies ist der Standardwert, entspricht sie der Angabe von clean: true für jeden Check-Out-Schritt in Ihrer Pipeline. Wenn Sie clean: true angeben, führen Sie vor dem git-Abruf git clean -ffdx gefolgt von git reset --hard HEAD aus. So konfigurieren Sie die Einstellung Bereinigen

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

   

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

   

Klassisch

Wenn Sie eine Pipeline auf einem selbstgehosteten Agent ausführen, wird zwischen zwei aufeinanderfolgenden Ausführungen standardmäßig keines der Unterverzeichnisse bereinigt. Dadurch können Sie inkrementelle Builds und Bereitstellungen durchführen, sofern Aufgaben implementiert sind, die diese Möglichkeit nutzen. Sie können dieses Verhalten jedoch mit der Option Clean build unter der Aufgabe Get sources außer Kraft setzen. Die Optionen variieren je nach Typ des verwendeten Repositorys.

• GitHub
• Azure Repos (Git)
• TFVC

Artefaktdownload

Diese YAML-Beispieldatei veröffentlicht das Artefakt WebSite und lädt das Artefakt dann nach $(Pipeline.Workspace) herunter. Der Bereitstellungsauftrag 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: $(Pipeline.Workspace)

  dependsOn: Build
  condition: succeeded()

Klassisch

In einer Releasepipeline können Sie den Download der Artefakte während der Auftragsausführung überspringen. Verwenden Sie diese Option, wenn Sie Ihre eigene benutzerdefinierte Logik für das Herunterladen von Artefakten mithilfe von Aufgaben implementieren möchten oder 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 auf bestimmten Artefakten basieren.

Informationen zur Verwendung vondependsOn und Bedingung finden Sie unter Angeben von Bedingungen.

Zugriff auf OAuth-Token

Sie können den in einem Auftrag ausgeführten Skripts 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. Er muss der Aufgabe oder dem Schritt explizit mit env zugewiesen werden. Hier sehen Sie 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)

Klassisch

Wählen Sie in den Steuerungsoptionen für den Auftrag die Option Skripts den Zugriff auf das OAuth-Token erlauben aus. Das Token steht als Umgebungsvariable SYSTEM_ACCESSTOKEN zur Verfügung.

Nächste Schritte

• Bereitstellungsgruppenaufträge
• Conditions (MSBuild-Bedingungen)