Hinzufügen von Phasen, Abhängigkeiten, & Bedingungen

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.

Das Konzept der Stufen variiert je nachdem, ob Sie YAML-Pipelines oder klassische Releasepipelinen verwenden.

Sie können Pipelineaufträge in Phasen organisieren. Phasen sind die wichtigsten Divisionen in einer Pipeline: "Erstellen Sie diese App", "führen Sie diese Tests aus", und "Bereitstellen in der Vorproduktion" sind gute Beispiele für Phasen. Sie sind logische Grenzen in Ihrer Pipeline, in der Sie die Pipeline anhalten und verschiedene Prüfungen durchführen können.

Jede Pipeline verfügt über mindestens eine Phase, auch wenn Sie sie nicht explizit definieren. Sie können Phasen auch in einem Abhängigkeitsdiagramm anordnen, sodass eine Phase vor einer anderen ausgeführt wird. Es gibt eine Grenze von 256 Aufträgen für eine Stufe.

Hinweis

Unterstützung für Stufen wurde in Azure DevOps Server 2019.1 hinzugefügt.

Diese Version von TFS unterstützt YAML nicht.

Angeben von Stufen

Hinweis

Unterstützung für Stufen wurde in Azure DevOps Server 2019.1 hinzugefügt.

Im einfachsten Fall benötigen Sie keine logischen Grenzen in Ihrer Pipeline. In diesem Fall müssen Sie das stage Schlüsselwort nicht explizit verwenden. Sie können die Aufträge in Ihrer YAML-Datei direkt angeben.

# this has one implicit stage and one implicit job
pool:
  vmImage: 'ubuntu-latest'
steps:
- bash: echo "Hello world"
# this pipeline has one implicit stage
jobs:
- job: A
  steps:
  - bash: echo "A"

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

Wenn Sie Ihre Pipeline in mehrere Phasen organisieren, verwenden Sie das stages Schlüsselwort.

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

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

Wenn Sie eine pool auf Stufeebene angeben möchten, verwenden alle in dieser Phase definierten Aufträge diesen Pool, sofern nicht anders auf der Auftragsebene angegeben.

Hinweis

In Azure DevOps Server 2019 können Pools nur auf Auftragsebene angegeben werden.

stages:
- stage: A
  pool: StageAPool
  jobs:
  - job: A1 # will run on "StageAPool" pool based on the pool defined on the stage
  - job: A2 # will run on "JobPool" pool
    pool: JobPool

Die vollständige Syntax zum Angeben einer Phase lautet:

stages:
- stage: string  # name of the stage, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  pool: string | pool
  variables: { string: string } | [ variable | variableReference ] 
  jobs: [ job | templateReference]

Diese Version von TFS unterstützt keine YAML-Pipelines.

Angeben von Abhängigkeiten

Hinweis

Unterstützung für Stufen wurde in Azure DevOps Server 2019.1 hinzugefügt.

Wenn Sie mehrere Phasen in einer Pipeline definieren, werden sie standardmäßig sequenziell in der Reihenfolge ausgeführt, in der Sie sie in der YAML-Datei definieren. Die Ausnahme hierfür ist, wenn Sie Abhängigkeiten hinzufügen. Bei Abhängigkeiten werden Phasen in der Reihenfolge der dependsOn Anforderungen ausgeführt.

Pipelines müssen mindestens eine Phase ohne Abhängigkeiten enthalten.

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

stages:
- stage: string
  dependsOn: string
  condition: string

Beispielphasen, die sequenziell ausgeführt werden:

# if you do not use a dependsOn keyword, stages run in the order they are defined
stages:
- stage: QA
  jobs:
  - job:
    ...

- stage: Prod
  jobs:
  - job:
    ...

Beispielphasen, die parallel ausgeführt werden:

stages:
- stage: FunctionalTest
  jobs:
  - job:
    ...

- stage: AcceptanceTest
  dependsOn: []    # this removes the implicit dependency on previous stage and causes this to run in parallel
  jobs:
  - job:
    ...

Beispiel für Fan-Out und Fan-In:

stages:
- stage: Test

- stage: DeployUS1
  dependsOn: Test    # this stage runs after Test

- stage: DeployUS2
  dependsOn: Test    # this stage runs in parallel with DeployUS1, after Test

- stage: DeployEurope
  dependsOn:         # this stage runs after DeployUS1 and DeployUS2
  - DeployUS1
  - DeployUS2

Diese Version von TFS unterstützt keine YAML-Pipelines.

Bedingungen

Sie können die Bedingungen angeben, unter denen jede Phase ausgeführt wird. Standardmäßig wird eine Phase ausgeführt, wenn sie nicht von einer anderen Phase abhängt oder ob alle Phasen, von denen sie abhängig ist, abgeschlossen und erfolgreich sind. Sie können dieses Verhalten anpassen, indem Sie eine Phase erzwingen, auch wenn eine vorherige Stufe fehlschlägt oder eine benutzerdefinierte Bedingung angibt.

Wenn Sie die Standardbedingung der vorherigen Schritte für eine Phase anpassen, entfernen Sie die Bedingungen für den Abschluss und den Erfolg. Wenn Sie also eine benutzerdefinierte Bedingung verwenden, ist and(succeeded(),custom_condition) es üblich, zu überprüfen, ob die vorherige Phase erfolgreich ausgeführt wurde. Andernfalls wird die Phase unabhängig vom Ergebnis der vorherigen Phase ausgeführt.

Hinweis

Fehlerbedingungen ('JOBNAME/STAGENAME') und erfolgreich ('JOBNAME/STAGENAME') wie im folgenden Beispiel gezeigt funktionieren nur für YAML-Pipelines.

Hinweis

Unterstützung für Stufen wurde in Azure DevOps Server 2019.1 hinzugefügt.

Beispiel zum Ausführen einer Phase basierend auf dem Status der Ausführung einer vorherigen Stufe:

stages:
- stage: A

# stage B runs if A fails
- stage: B
  condition: failed()

# stage C runs if B succeeds
- stage: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')

Beispiel für die Verwendung einer benutzerdefinierten Bedingung:

stages:
- stage: A

- stage: B
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/main'))

Diese Version von TFS unterstützt keine YAML-Pipelines.

Angeben von Warteschlangenrichtlinien

YAML-Pipelines unterstützen keine Warteschlangenrichtlinien. Jede Ausführung einer Pipeline ist unabhängig von anderen Läufen. Mit anderen Worten, Ihre beiden aufeinander folgenden Commits können zwei Pipelines auslösen, und beide werden dieselbe Abfolge von Phasen ausführen, ohne aufeinander zu warten. Während wir arbeiten, um Queuing-Richtlinien in YAML-Pipelines zu bringen, empfehlen wir, manuelle Genehmigungen zu verwenden, um die Reihenfolge manuell zu sequenzieren und zu steuern, wenn dies von Bedeutung ist.

Diese Version von TFS unterstützt keine YAML-Pipelines.

Angeben von Genehmigungen

Sie können manuell steuern, wann eine Phase mithilfe von Genehmigungsprüfungen ausgeführt werden soll. Dies wird häufig verwendet, um Bereitstellungen in Produktionsumgebungen zu steuern. Überprüfungen sind ein Mechanismus, der dem Ressourcenbesitzer zur Verfügung steht, um zu steuern, ob und wann eine Phase in einer Pipeline eine Ressource nutzen kann. Als Besitzer einer Ressource, z. B. einer Umgebung, können Sie Überprüfungen definieren, die erfüllt sein müssen, bevor eine Phase, in der diese Ressource verbraucht wird, gestartet werden kann.

Derzeit werden manuelle Genehmigungsprüfungen in Umgebungen unterstützt. Weitere Informationen finden Sie unter Genehmigungen.

Genehmigungen werden in YAML-Pipelines in dieser Version von Azure DevOps Server noch nicht unterstützt.

Diese Version von TFS unterstützt keine YAML-Pipelines.