Hinzufügen von Stages, Abhängigkeiten und Bedingungen

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

Eine Stage ist eine logische Grenze in einer Azure DevOps-Pipeline. Stages können zum Gruppieren von Aktionen in Ihrem Softwareentwicklungsprozess (z. B. „Die App erstellen“, „Den Test ausführen“, „In der Präproduktionsumgebung bereitstellen“) verwendet werden. Eine Stage enthält mindestens einen Auftrag.

Wenn Sie mehrere Stages in einer Pipeline definieren, werden diese standardmäßig nacheinander ausgeführt. Stages können auch voneinander abhängen. Sie können das dependsOn Schlüsselwort zum Definieren von Abhängigkeiten verwenden. Stages können auch basierend auf dem Ergebnis einer vorherigen Stage ausgeführt werden, für die Bedingungen definiert wurden.

Informationen zur Funktionsweise von Stages mit parallelen Aufträgen und Lizenzierung finden Sie unter Konfigurieren und Bezahlen von parallelen Aufträgen.

Informationen dazu, wie Stages mit anderen Teilen einer Pipeline wie Aufträgen in Beziehung stehen, finden Sie unter Schlüsselpipelinekonzepte.

Weitere Informationen zur Beziehung zwischen Stages und Teilen einer Pipeline finden Sie auch im Artikel zu den YAML-Schemastages.

YAML

Pipelineaufträge können in Phasen strukturiert werden. Phasen stellen die Hauptunterteilungen in einer Pipeline dar. Einige gute Beispiele für Phasen sind „Diese App erstellen“, „Diese Tests ausführen“ und „In der Präproduktionsumgebung bereitstellen“. Sie fungieren als logische Abgrenzungen in Ihrer Pipeline, bei denen Sie die Pipeline anhalten und verschiedene Überprüfungen durchführen können.

Jede Pipeline verfügt über mindestens eine Stage, auch wenn Sie sie nicht explizit definieren. Sie können Stages auch in einem Abhängigkeitsdiagramm anordnen, sodass eine Stage vor einer anderen ausgeführt wird. Eine Phase ist auf 256 Aufträge begrenzt.

Klassisch

Strukturieren Sie die Bereitstellungsaufträge in Ihrer Releasepipeline in Phasen. Phasen stellen die Hauptunterteilungen in Ihrer Releasepipeline dar: „Funktionstests ausführen“, „In der Präproduktionsumgebung bereitstellen“ und „In der Produktionsumgebung bereitstellen“ sind gute Beispiele für Releasephasen.

Eine Stage in einer Releasepipeline besteht aus Aufträgen und Aufgaben.

Genehmigungen und Gates, Bereitstellungsbedingungen und Trigger sowie Warteschlangenrichtlinien steuern, wann ein Release in einer Stage bereitgestellt wird.

Festlegen von Stages

YAML

Im einfachsten Fall benötigen Sie keine logischen Grenzen in Ihrer Pipeline. In diesem Fall müssen Sie das Schlüsselwort stage nicht explizit verwenden. Sie können die Aufträge direkt in Ihrer YAML-Datei 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 mehreren Stages organisieren, verwenden Sie das Schlüsselwort stages.

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

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

Wenn Sie einen pool auf der Phasenebene angeben, verwenden alle in dieser Phase definierten Aufträge diesen Pool, sofern sie nicht auf Auftragsebene angegeben sind.

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 Festlegen einer Stage 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]

Klassisch

Um Ihrer Releasepipeline eine Stage hinzuzufügen, wählen Sie auf der Seite Releases die Releasepipeline aus, wählen Sie die Aktion aus, um diese zu Bearbeiten, und wählen Sie dann die Registerkarte Pipeline aus. Während der wichtigste Teil beim Definieren einer Stage die Automatisierungsaufgaben sind, können Sie auch mehrere Eigenschaften und Optionen für eine Stage in einer Releasepipeline konfigurieren. Ihre Möglichkeiten:

• Bearbeiten Sie ggf. den Namen der Stage hier.
• Legen Sie einen Benutzer bzw. eine Benutzerin oder eine Gruppe als Stagebesitzer*in fest. Stagebesitzer*innen werden benachrichtigt, wenn eine Bereitstellung in dieser Stage fehlschlägt. Der Besitz einer Stage bringt nicht automatisch irgendwelche Berechtigungen mit sich.
• Löschen Sie die Stage aus der Pipeline.
• Ändern sie die Reihenfolge der Stages.
• Speichern Sie eine Kopie der Stage als Stagevorlage.
• Verwalten Sie die Sicherheitseinstellungen für die Stage.

Angeben von Abhängigkeiten

YAML

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

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

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

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

Beispiel für Stages, 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:
    ...

Beispiel für Stages, 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 das Auffächern nach innen und nach außen:

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

Klassisch

Sie steuern die Abhängigkeiten, indem Sie die Trigger für jede Stage der Releasepipeline festlegen:

• Stages werden mit einem Trigger oder manuell gestartet.
• Ein Nach dem Release-Trigger löst eine Phase aus, sobald das Release gestartet wird. Sie wird parallel zu anderen Phasen ausgeführt, für die ein Nach dem Release-Trigger festgelegt wurde.
• Mit einem Trigger Nach einer Stage wird eine Stage gestartet, nachdem alle abhängigen Stages abgeschlossen sind. Auf diese Weise können Sie das Verhalten zum Auffächern nach innen und nach außen für Stages modellieren.

Definieren von Bedingungen

Sie können die Bedingungen angeben, unter denen jede Stage mit Ausdrücken ausgeführt wird. Standardmäßig wird eine Stage ausgeführt, wenn sie nicht von einer anderen Stage abhängt oder wenn alle Stages, von denen sie abhängt, abgeschlossen und erfolgreich sind. Sie können dieses Verhalten anpassen, indem Sie die Ausführung einer Stage erzwingen, auch wenn eine vorherige Stage fehlschlägt, oder indem Sie eine benutzerdefinierte Bedingung angeben.

Wenn Sie die Standardbedingung der vorherigen Schritte für eine Stage anpassen, entfernen Sie die Bedingungen für Abschluss und Erfolg. Wenn Sie also eine benutzerdefinierte Bedingung verwenden, wird häufig mithilfe von and(succeeded(),custom_condition) überprüft, ob die vorherige Stage erfolgreich ausgeführt wurde. Andernfalls wird die Stage unabhängig vom Ergebnis der vorherigen Stage ausgeführt.

Hinweis

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

YAML

Beispiel für die Ausführung einer Stage basierend auf dem Status der Ausführung einer vorherigen Stage:

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'))

Klassisch

Wenn Sie die Trigger Nach einem Release oder Nach einer Stage angeben, können Sie auch die Branchfilter für die im Release verwendeten Artefakte angeben. Releases werden nur in einer Stage bereitgestellt, wenn die Branchfilter erfüllt sind.

Festlegen von Warteschlangenrichtlinien

YAML

YAML-Pipelines unterstützen keine Warteschlangenrichtlinien. Jede Ausführung einer Pipeline ist unabhängig von anderen Ausführungen. Anders ausgedrückt: Ihre beiden aufeinander folgenden Commits können zwei Pipelines auslösen, und beide führen die gleiche Sequenz von Stages aus, ohne aufeinander zu warten. Während wir daran arbeiten, Warteschlangenrichtlinien in YAML-Pipelines einzusetzen, empfiehlt es sich, manuelle Genehmigungen zu verwenden, um die Reihenfolge der Ausführung bei Bedarf manuell steuern zu können.

Klassisch

In einigen Fällen können Sie Builds möglicherweise schneller generieren, als sie bereitgestellt werden können. Alternativ haben Sie die Möglichkeit, mehrere Agents zu konfigurieren und beispielsweise Releases aus derselben Releasepipeline für die Bereitstellung verschiedener Artefakte zu erstellen. In solchen Fällen ist es hilfreich, steuern zu können, wie mehrere Releases in eine Stage eingereiht werden. Warteschlangenrichtlinien geben Ihnen diese Kontrollmöglichkeit.

Sie können folgende Optionen für eine Warteschlangenrichtlinie auswählen:

• Anzahl paralleler Bereitstellungen: Verwenden Sie diese Option, wenn Sie neue Ressourcen dynamisch in Ihrer Stage bereitstellen und physisch in der Lage sind, die Bereitstellung mehrerer Releases parallel zu verarbeiten, aber Sie möchten die Anzahl paralleler Bereitstellungen begrenzen.

• Wenn Sie eine maximale Anzahl von Bereitstellungen angeben, werden zwei weitere Optionen angezeigt:

  • Alle in Sequenz bereitstellen: Verwenden Sie diese Option, wenn Sie alle Releases sequenziell in den gleichen freigegebenen physischen Ressourcen bereitstellen möchten. Indem Sie die Builds nacheinander bereitstellen, stellen Sie sicher, dass zwei Bereitstellungsaufträge nicht gleichzeitig auf dieselben physischen Ressourcen abzielen, auch wenn mehrere Build- und Release-Agents verfügbar sind. Außerdem stellen Sie dadurch sicher, dass Genehmigungsanforderungen für die Phase vor der Bereitstellung nacheinander gesendet werden.

  • Aktuelle Version bereitstellen und andere abbrechen: Verwenden Sie diese Option, wenn Sie Builds schneller als Releases erstellen und nur den neuesten Build bereitstellen möchten.

Um zu verstehen, wie diese Optionen funktionieren, betrachten Sie ein Szenario, in dem die Releases R1, R2, ..., R5 einer einzelnen Releasepipeline in kurzer Folge erstellt werden. Angenommen, die erste Phase in dieser Pipeline heißt QA und es wurden für sie Genehmigende für die Phase vor und nach der Bereitstellung definiert.

• Wenn Sie für die Anzahl der parallelen Bereitstellungen keine Grenze angeben, werden alle fünf Genehmigungsanforderungen gesendet, sobald die Releases erstellt wurden. Wenn die genehmigenden Personen alle Releases genehmigen, werden sie alle parallel in der Stage QA bereitgestellt. (wenn für die QA-Phase vor der Bereitstellung keine Genehmigenden definiert wurden, werden alle fünf Releases automatisch parallel zu dieser Phase bereitgestellt.

• Wenn Sie eine Grenze festlegen und Alle nacheinander bereitstellen auswählen, und wenn die Grenze bereits erreicht wurde, wird zuerst die Genehmigung nach der Bereitstellung für Release R1 gesendet. Nach Abschluss dieser Genehmigung beginnt die Bereitstellung von Release R1 in der Stage QA. Als Nächstes wird eine Anforderung für die Genehmigung nach der Bereitstellung für Release R1 gesendet. Erst wenn diese Genehmigung nach der Bereitstellung abgeschlossen wurde, wird Release R2 ausgeführt, und es wird die Genehmigung vor der Bereitstellung gesendet. Derselbe Prozess wird für alle Releases nacheinander fortgesetzt.

• Wenn Sie eine Grenze festlegen und Aktuelle bereitstellen und die anderen löschen wählen, und wenn die Grenze bereits erreicht wurde, werden die Releases R2, R3 und R4 übersprungen und es wird die Genehmigung vor der Bereitstellung für R5 in der QA-Phase gesendet, nachdem die Genehmigung nach der Bereitstellung für Release R1 abgeschlossen wurde.

Festlegen von Genehmigungen

YAML

Mithilfe von Genehmigungsüberprüfungen können Sie manuell steuern, wann eine Stage ausgeführt werden soll. Diese Überprüfung 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 Stage in einer Pipeline eine Ressource nutzen kann. Als Besitzer*in einer Ressource, z. B. einer Umgebung, können Sie Überprüfungen definieren, die bestanden werden müssen, bevor eine Stage, die diese Ressource nutzt, beginnen kann.

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

Klassisch

Sie können manuelle Genehmigungen am Anfang oder Ende jeder Stage in der Pipeline hinzufügen. Weitere Informationen finden Sie unter Übersicht über Releasegenehmigungen und Gates.

Manuellen Trigger hinzufügen

Manuell ausgelöste YAML-Pipelinephasen ermöglichen es Ihnen, eine einheitliche Pipeline zu haben, ohne sie immer zum Abschluss auszuführen.

Ihre Pipeline kann z. B. Phasen für das Erstellen, Testen, Bereitstellen in einer Stagingumgebung und die Bereitstellung in der Produktion umfassen. Möglicherweise möchten Sie, dass alle Phasen automatisch ausgeführt werden, mit Ausnahme der Produktionsbereitstellung, die Sie bei Bedarf manuell auslösen möchten.

Um dieses Feature zu verwenden, fügen Sie die trigger: manual Eigenschaft zu einer Phase hinzu.

Im folgenden Beispiel wird die Entwicklungsphase automatisch ausgeführt, während für die Produktionsphase manuelles Auslösen erforderlich ist. Beide Phasen führen ein Hello World-Ausgabeskript aus.

stages:
- stage: development
  displayName: Deploy to development
  jobs:
  - job: DeployJob
    steps:
    - script: echo 'hello, world'
      displayName: 'Run script'
- stage: production
  displayName: Deploy to production
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - script: echo 'hello, world'
      displayName: 'Run script'

Eine Phase als nicht überspringbar markieren

Markieren Sie eine Phase, um isSkippable: false zu verhindern, dass Pipelinebenutzer Phasen überspringen. Beispielsweise verfügen Sie möglicherweise über eine YAML-Vorlage, die eine Phase einführt, die Schadsoftwareerkennung in allen Pipelines durchführt. Wenn Sie diese Phase festlegen isSkippable: false , kann Pipeline die Erkennung von Schadsoftware nicht überspringen.

Im folgenden Beispiel wird die Malware-Erkennungsphase als nicht überspringbar gekennzeichnet, d. h. sie muss als Teil der Pipelineausführung ausgeführt werden.

- stage: malware_detection
  displayName: Malware detection
  isSkippable: false
  jobs:
  - job: check_job
    ...

Wenn eine Phase nicht überspringbar ist, wird sie mit einem deaktivierten Kontrollkästchen im Abschnitt „Phasen” angezeigt, um den Konfigurationsbereich auszuführen.