Hinzufügen von Phasen, 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. Stufen Sie Gruppenaktionen in Ihrem Softwareentwicklungsprozess auf, z. B. das Erstellen der App, das Ausführen von Tests und die Bereitstellung für die Vorproduktion. 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 Phase, 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 Stufe kann bis zu 256 Arbeitsplätze haben.

Klassisch

Strukturieren Sie die Bereitstellungsaufträge in Ihrer Releasepipeline in Phasen. Phasen sind die wichtigsten Bereiche in Ihrer Releasepipeline. Beispiele hierfür sind das Ausführen von Funktionstests, die Bereitstellung in der Vorproduktion und die Bereitstellung in der Produktion.

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. Für diese Szenarien können Sie die Aufträge in Ihrer YAML-Datei ohne das stages Schlüsselwort direkt angeben. Wenn Sie beispielsweise über eine einfache Pipeline verfügen, die eine kleine Anwendung erstellt und testet, ohne dass separate Umgebungen oder Bereitstellungsschritte erforderlich sind, können Sie alle Aufträge direkt definieren, ohne Phasen zu verwenden.

pool:
  vmImage: 'ubuntu-latest'

jobs:
- job: BuildAndTest
  steps:
  - script: echo "Building the application"
  - script: echo "Running tests"

Diese Pipeline verfügt über eine implizite Stufe und zwei Jobs. Das stages Schlüsselwort wird nicht verwendet, da es nur eine Phase gibt.

jobs:
- job: Build
  steps:
  - bash: echo "Building"

- job: Test
  steps:
  - bash: echo "Testing"

Verwenden Sie das stages Schlüsselwort, um Ihre Pipeline in mehrere Phasen zu organisieren. Dieser YAML definiert eine Pipeline mit zwei Phasen, in denen jede Phase mehrere Aufträge enthält, und jeder Auftrag verfügt über spezifische Schritte zur Ausführung.

stages:
- stage: A
  displayName: "Stage A - Build and Test"
  jobs:
  - job: A1
    displayName: "Job A1 - build"
    steps:
    - script: echo "Building the application in Job A1"
      displayName: "Build step"
  - job: A2
    displayName: "Job A2 - Test"
    steps:
    - script: echo "Running tests in Job A2"
      displayName: "Test step"

- stage: B
  displayName: "Stage B - Deploy"
  jobs:
  - job: B1
    displayName: "Job B1 - Deploy to Staging"
    steps:
    - script: echo "Deploying to staging in Job B1"
      displayName: "Staging deployment step"
  - job: B2
    displayName: "Job B2 - Deploy to Production"
    steps:
    - script: echo "Deploying to production in Job B2"
      displayName: "Production deployment step"

Wenn Sie eine pool auf Stufenebene angeben, verwenden alle Jobs in dieser Stufe diesen Pool, es sei denn, die Stufe wird auf der Job-Ebene angegeben.

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

Klassisch

Wenn Sie Ihrer Releasepipeline eine Phase hinzufügen möchten, wählen Sie die Releasepipeline auf der Seite "Releases" aus, wählen Sie "Bearbeiten" und dann die Registerkarte "Pipeline" aus. Während der wichtigste Teil der Definition einer Phase die Automatisierungsaufgaben sind, können Sie auch mehrere Eigenschaften und Optionen für eine Phase 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 Phasenbesitz enthält nicht automatisch Berechtigungen.
• 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 sie standardmäßig 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.

Weitere Informationen zum Definieren von Phasen finden Sie in den Phasen im YAML-Schema.

Die folgenden Beispielphasen werden sequenziell ausgeführt. Wenn Sie kein Schlüsselwort verwenden dependsOn , werden Phasen in der Reihenfolge ausgeführt, in der sie definiert sind.

stages:
- stage: Build
  displayName: "Build Stage"
  jobs:
  - job: BuildJob
    steps:
    - script: echo "Building the application"
      displayName: "Build Step"

- stage: Test
  displayName: "Test Stage"
  jobs:
  - job: TestJob
    steps:
    - script: echo "Running tests"
      displayName: "Test Step"

Beispiel für Stages, die parallel ausgeführt werden:

stages:
- stage: FunctionalTest
  displayName: "Functional Test Stage"
  jobs:
  - job: FunctionalTestJob
    steps:
    - script: echo "Running functional tests"
      displayName: "Run Functional Tests"

- stage: AcceptanceTest
  displayName: "Acceptance Test Stage"
  dependsOn: [] # Runs in parallel with FunctionalTest
  jobs:
  - job: AcceptanceTestJob
    steps:
    - script: echo "Running acceptance tests"
      displayName: "Run Acceptance Tests"

Beispiel für Fan-out- und Fan-In-Verhalten.

stages:
- stage: Test

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

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

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

Klassisch

Steuern von Abhängigkeiten durch Festlegen von Triggern in jeder Phase der Releasepipeline:

• Phasen werden mit einem Trigger ausgeführt oder manuell gestartet.
• Bei einem After Release-Auslöser wird eine Stufe gestartet, sobald die Veröffentlichung beginnt und wird parallel zu anderen Stufen mit demselben Auslöser ausgeführt.
• Mit einem After-Stage-Trigger beginnt eine Phase, nachdem alle abhängigen Phasen abgeschlossen wurden. 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. Mit anderen Worten, Ihre beiden aufeinander folgenden Commits lösen möglicherweise zwei Pipelines aus, und beide führen dieselbe Sequenz von Phasen aus, ohne auf einander 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 möglicherweise schneller Builds generieren, als sie bereitgestellt werden können. Alternativ können Sie mehrere Agents konfigurieren und beispielsweise Freigaben aus derselben Release-Pipeline für die Bereitstellung verschiedener Artefakte 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. Sie können z. B. eine YAML-Vorlage haben, die eine Phase einführt, in der Schadsoftwareerkennung in allen Pipelines ausgeführt wird. Wenn Sie isSkippable: false für diese Phase festlegen, kann Ihre Pipeline die Erkennung von Schadsoftware nicht überspringen.

Im folgenden Beispiel wird die Schadsoftwareerkennungsphase als nichtskippierbar markiert, 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 Konfigurationsbereich 'auszuführende Phasen' angezeigt.