Erstellen einer YAML-Pipeline mit Phasen

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

Mit mehreren Stufen können Sie verschiedene Teile Ihrer Pipeline isolieren, die Qualitätskontrolle und Die Sicherheit verbessern, einen besseren Einblick in den Fortschritt der Pipeline haben und Risiken verringern.

In diesem Artikel erfahren Sie, wie Sie eine komplexere YAML-Pipeline mit mehreren Phasen und Bedingungen erstellen und ausführen. Die Beispielpipeline umfasst Build-, Test- und Bereitstellungsphasen sowie optionale Phasen für alternative Bereitstellungen und Rollbacks. Mit der Rollbackphase können Sie schnell zu einer stabilen Version zurückkehren, wenn etwas schief geht. Dies erhöht die Zuverlässigkeit und Stabilität.

Dieser Code funktioniert für die meisten Szenarien, enthält jedoch keine sprach- oder plattformspezifischen Anforderungen. Passen Sie im nächsten Schritt die Pipeline an Ihre spezifischen Implementierungsanforderungen an.

Wie Sie eine Classic Pipeline mit Stages erstellen können, erfahren Sie unter Bereitstellen auf verschiedenen Stages von mehreren Branches mit Classic Release Pipelines.

Voraussetzungen

Produkt Anforderungen
Azure DevOps - Ein Azure DevOps-Projekt.
– Eine Möglichkeit zum Ausführen von Pipelines auf von Microsoft gehosteten Agenten. Sie können entweder einen Parallelauftrag erwerben oder einen Free-Tarif anfordern.
- Grundkenntnisse in YAML und Azure Pipelines. Weitere Informationen finden Sie unter Erstellen Sie Ihre erste Pipeline.
- Berechtigungen:
     Benutzer, die eine Pipeline erstellen wollen, müssen Mitglied der Gruppe Mitwirkende sein, und für die Gruppe muss die Berechtigung Buildpipeline erstellen auf „Zulassen“ festgelegt sein. Mitglieder der Gruppen "Buildadministratoren" und "Projektadministratoren " können auch Pipelines verwalten.
GitHub (Englisch) - Ein GitHub-Konto .
– Eine GitHub-Dienstverbindung zum Autorisieren von Azure Pipelines.
Azurblau Ein Azure-Abonnement.

1. Erstellen einer Startpipeline

  1. Wählen Sie in Ihrem Azure DevOps-Projekt pipelinesCreate Pipelines aus, und wählen Sie > als Speicherort Ihres Quellcodes aus.
  2. Wählen Sie auf dem Bildschirm " Repository auswählen " Ihr Repository aus.
  3. Wählen Sie auf dem Bildschirm "Pipeline konfigurieren" die Option "Startpipeline" aus.
  4. Ihre Pipeline speichern.

2. Fügen Sie die Build-Stufe hinzu

Die Startpipeline, die Sie in der vorherigen Phase hinzugefügt haben, war ein Platzhalter. Entfernen Sie den Startpipelinecode, und fügen Sie eine neue YAML-Pipeline mit einer Buildphase hinzu.

  1. Entfernen Sie den gesamten Code in Ihrer Pipeline.

  2. Ersetzen Sie den Code durch den folgenden YAML-Code, der eine Build Phase enthält.

    trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

stages:
- stage: Build
  displayName: 'Build Stage'
  jobs:
  - job: BuildJob
    displayName: 'Build Job'
    steps:
    - script: |
        echo "Restoring project dependencies..."
      displayName: 'Restore dependencies'
    - script: |
        echo "Running unit tests..."
      displayName: 'Run unit tests'

In dieser Build Stufe und in der gesamten Pipeline des Beispiels gibt es Platzhalter für Skriptaufgaben. Ersetzen Sie beim Erstellen einer funktionierenden Pipeline die Platzhalterbefehle wie Restoring project dependencies... durch tatsächlichen Code.

In diesem Beispiel stellen Sie Abhängigkeiten wieder her und führen Komponententests aus, um sicherzustellen, dass der Code zum Testen und Bereitstellen bereit ist. Wenn Ihre Anwendung Quellcode kompilieren muss, geschieht dies auch in der Build Phase.

3. Hinzufügen der Testphase

Die Test Phase führt Tests für das Projekt aus und veröffentlicht die Testergebnisse in Azure DevOps. Weitere Informationen zum Veröffentlichen von Testergebnissen finden Sie unter Aufgabe "Testergebnisse veröffentlichen".

Die Test Phase wird nur ausgeführt, wenn die Build Phase erfolgreich abgeschlossen ist und die Phase nicht übersprungen werden kann.

Fügen Sie die Test-Phase nach der Build-Phase in Ihrer Pipeline hinzu.

- stage: Test
  displayName: 'Test Stage'
  dependsOn: Build
  isSkippable: false
  jobs:
  - job: TestJob
    displayName: 'Test Job'
    steps:
    - script: |
        echo "Running unit tests..."
      displayName: 'Run unit tests'

Die Testphase enthält ein Attribut, das isSkippable auf false setzt. Wenn Sie isSkippable auf false setzen, kann eine Phase nicht übersprungen werden. Die Option zum Überspringen der Phase ist auch in der Azure DevOps-Benutzeroberfläche deaktiviert.

Screenshot der Phase, die nicht übersprungen werden kann.

4. Bereitstellung der Phase

Fügen Sie die DeployToStaging-Phase nach der Test-Phase in Ihrer Pipeline hinzu.

Die DeployToStaging Phase hängt von der auszuführenden Test-Phase ab. Es gibt zwei verschiedene Aufgaben in der DeployToStaging Phase - DeployStagingJob und DeployStagingJobWithValidation. Die DeployStagingJob sollte den Code enthalten, um Ihren Job für die Bereitstellung von Ressourcen wie einem Staging-Server bereitzustellen.

Der DeployStagingJobWithValidation Job enthält die gesamte Validierung, die mit der Bereitstellung Ihres Staging-Systems einhergeht. Für den DeployStagingJobWithValidation-Auftrag ist eine manuelle Genehmigung erforderlich. Die manuelle Überprüfungsaufgabe hält die Pipelineausführung an und wartet auf eine manuelle Interaktion. Ein Benutzer muss die Phase validieren, bevor die Ausführung fortgesetzt wird. Durch die manuelle Genehmigung in Ihrer Pipeline wird eine zusätzliche Sicherheitsstufe hinzugefügt, Risiken werden verringert und es wird sichergestellt, dass alle Änderungen von den entsprechenden Interessensgruppen überprüft werden.

Der Pool für die manuelle Genehmigung ist server. Manuelle Überprüfungen werden nur auf einem Serverpool ausgeführt.

- stage: DeployToStaging
  displayName: 'Deploy to Staging'
  dependsOn: Test
  jobs:
  - job: DeployStagingJob
    displayName: 'Deploy to Staging Job'
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - script: |
        echo "Build staging job..."
      displayName: 'Build and deploy to staging'

  - job: DeployStagingJobWithValidation
    pool: server
    timeoutInMinutes: 4320 # job times out in 3 days
    displayName: 'Deploy to Staging Job'
    steps:
    - task: ManualValidation@1
      timeoutInMinutes: 1440 # task times out in 1 day
      inputs:
        notifyUsers: user@example.com
        instructions: 'Please validate the stage configuration and resume'
        onTimeout: 'resume'

5. Bereitstellung für die Produktion:

Fügen Sie die DeployToProduction-Phase nach der DeployToStaging-Phase in Ihrer Pipeline hinzu.

In der DeployToProduction-Stufe wird die Anwendung für die Produktion bereitgestellt, aber nur, wenn die DeployToStaging-Stufe erfolgreich ist und der Quellzweig entweder main oder release ist.

Es gibt zwei verschiedene Aufgaben in der DeployToProduction Phase - DeployProductionJob und waitForValidation.

Die manuelle Überprüfungsaufgabe fügt waitForValidation einen zweiten menschlichen Validierungsschritt für Sicherheit und Qualitätskontrolle hinzu. Wir haben auch einen manuellen Validierungsprozess in der DeployToStaging-Phase verwendet.

- stage: DeployToProduction
  displayName: 'Deploy to Production'
  dependsOn: DeployToStaging
  lockBehavior: sequential
  condition: and(succeeded(), in(variables['Build.SourceBranch'], 'refs/heads/main', 'refs/heads/release'))
  jobs:
  - job: DeployProductionJob
    displayName: 'Deploy to Production Job'
    steps:
    - script: |
        echo "Deploying to production..."
        # Add your deployment commands here
      displayName: 'Run deployment commands'
  - job: waitForValidation
    displayName: Wait for external validation
    pool: server
    timeoutInMinutes: 4320 # job times out in 3 days
    steps:
    - task: ManualValidation@1
      timeoutInMinutes: 1440 # task times out in 1 day
      inputs:
        notifyUsers: user@example.com
        instructions: 'Please validate the build configuration and resume'
        onTimeout: 'resume'

6. Hinzufügen optionaler alternativer Produktions- und Rollbackphasen

Sie können optional zwei Phasen DeployToAlternateProduction und Rollback nach der DeployToProduction Phase hinzufügen.

DeployToAlternateProduction und Rollback sind manuell in die Warteschlange gestellt. In der Phase DeployToAlternateProduction haben Sie eine Backup-Produktionsumgebung bereit, falls Ihre primäre Umgebung ausfällt. Eine Umgebung kann eine Azure DevOps-Umgebung oder ein anderer Ort wie ein anderer Cloudanbieter sein. Dadurch wird die Gesamtsicherheit und Verfügbarkeit Ihrer Anwendung verbessert. Möglicherweise möchten Sie auch eine alternative Bereitstellungsumgebung für Notfallwiederherstellung oder Tests und Validierungen verwenden. Komplexere Bereitstellungsstrategien finden Sie unter Bereitstellungsaufträge und Hinzufügen von Phasen, Abhängigkeiten und Bedingungen.

Die Rollback-Phase bietet ein Sicherheitsnetz, um Ihre Anwendung auf einen zuvor stabilen Zustand zurückzusetzen, wenn während oder nach einer Bereitstellung etwas schiefgeht. Dies kann aufgrund eines Bereitstellungsfehlers, eines Fehlers, einer Complianceanforderung, einer Notfallwiederherstellung oder eines anderen Problems auftreten. Eine Rollbackstufe ist für die Aufrechterhaltung der Stabilität und Zuverlässigkeit Ihrer Anwendung unerlässlich.

- stage: DeployToAlternateProduction
  displayName: 'Deploy to Alternate Production'
  condition: succeeded()
  trigger: manual
  jobs:
  - job: DeployAlternateProductionJob
    displayName: 'Deploy to Alternate Production Job'
    steps:
    - script: |
        echo "Deploying to alternate production..."
        # Add your deployment commands here
      displayName: 'Run deployment commands'

- stage: Rollback
  displayName: 'Rollback Stage'
  trigger: manual
  jobs:
  - job: RollbackJob
    displayName: 'Rollback Job'
    steps:
    - script: |
        echo "Rolling back the deployment..."
        # Add your rollback commands here
      displayName: 'Run rollback commands'

Die gesamte YAML-Pipeline anzeigen

Hier ist die gesamte Pipeline mit allen referenzierten Stufen.

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

stages:
- stage: Build
  displayName: 'Build Stage'
  jobs:
  - job: BuildJob
    displayName: 'Build Job'
    steps:
    - script: |
        echo "Restoring project dependencies..."
      displayName: 'Restore dependencies'
    - script: |
        echo "Running unit tests..."
      displayName: 'Run unit tests'

- stage: Test
  displayName: 'Test Stage'
  dependsOn: Build
  isSkippable: false
  jobs:
  - job: TestJob
    displayName: 'Test Job'
    steps:
    - script: |
        echo "Running unit tests..."
      displayName: 'Run unit tests'


- stage: DeployToStaging
  displayName: 'Deploy to Staging'
  dependsOn: Test
  jobs:
  - job: DeployStagingJob
    displayName: 'Deploy to Staging Job'
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - script: |
        echo "Build staging job..."
      displayName: 'Build and deploy to staging'

  - job: DeployStagingJobWithValidation
    pool: server
    timeoutInMinutes: 4320 # job times out in 3 days
    displayName: 'Deploy to Staging Job'
    steps:
    - task: ManualValidation@1
      timeoutInMinutes: 1440 # task times out in 1 day
      inputs:
        notifyUsers: user@example.com
        instructions: 'Please validate the stage configuration and resume'
        onTimeout: 'resume'

- stage: DeployToProduction
  displayName: 'Deploy to Production'
  dependsOn: DeployToStaging
  lockBehavior: sequential
  condition: and(succeeded(), in(variables['Build.SourceBranch'], 'refs/heads/main', 'refs/heads/release'))
  jobs:
  - job: DeployProductionJob
    displayName: 'Deploy to Production Job'
    steps:
    - script: |
        echo "Deploying to production..."
        # Add your deployment commands here
      displayName: 'Run deployment commands'
  - job: waitForValidation
    displayName: Wait for external validation
    pool: server
    timeoutInMinutes: 4320 # job times out in 3 days
    steps:
    - task: ManualValidation@1
      timeoutInMinutes: 1440 # task times out in 1 day
      inputs:
        notifyUsers: user@example.com
        instructions: 'Please validate the build configuration and resume'
        onTimeout: 'resume'

- stage: DeployToAlternateProduction
  displayName: 'Deploy to Alternate Production'
  condition: succeeded()
  trigger: manual
  jobs:
  - job: DeployAlternateProductionJob
    displayName: 'Deploy to Alternate Production Job'
    steps:
    - script: |
        echo "Deploying to alternate production..."
        # Add your deployment commands here
      displayName: 'Run deployment commands'

- stage: Rollback
  displayName: 'Rollback Stage'
  trigger: manual
  jobs:
  - job: RollbackJob
    displayName: 'Rollback Job'
    steps:
    - script: |
        echo "Rolling back the deployment..."
        # Add your rollback commands here
      displayName: 'Run rollback commands'

Nächste Schritte

Hinzufügen von Stages, Abhängigkeiten und Bedingungen

  • Last updated on