Vorschau und Genehmigung Ihrer Bereitstellung

Sie haben nun die Pipelinephasen kennen gelernt und erfahren, wie Sie eine Pipelinephase hinzufügen können, um Ihren Bicep-Code zu überprüfen. Der nächste Schritt beim Aufbau von Vertrauen in Ihre Bereitstellung besteht darin, eine weitere Phase hinzuzufügen, um genau zu überprüfen, was durch Ihre Bereitstellung geändert wird.

In dieser Lerneinheit erfahren Sie mehr über die Verwendung des Befehls „what-if“ in einer Pipeline. Außerdem erfahren Sie mehr über das Hinzufügen von Genehmigungen, damit Sie die Ausgabe des Befehls manuell überprüfen können, bevor die Bereitstellung erfolgt.

Der Was-wäre-wenn-Vorgang

In einer Bicep-Datei wird der Zustand beschrieben, in dem sich Ihre Azure-Umgebung am Ende einer Bereitstellung befinden soll. Wenn Sie eine Bereitstellung übermitteln, ändert Azure Resource Manager Ihre Azure-Umgebung so, dass sie dem In Ihrer Bicep-Datei beschriebenen Zustand entspricht.

Eine Bereitstellung kann dazu führen, dass neue Ressourcen in Ihrer Umgebung bereitgestellt werden oder vorhandene Ressourcen aktualisiert werden. Wenn Sie eine Bereitstellung im vollständigen Modus ausführen, kann das sogar dazu führen, dass vorhandene Ressourcen gelöscht werden.

Wenn Ressourcen erstellt, aktualisiert oder gelöscht werden, besteht das Risiko, dass sich die Dinge in einer Weise ändern können, die Sie nicht erwarten. Es ist eine bewährte Methode, einen zusätzlichen Schritt hinzuzufügen, um zu überprüfen, welche Ressourcen genau erstellt, aktualisiert und gelöscht wird. Diese Überprüfung verbessert Ihren Automatisierungsprozess. Wenn Sie die Bereitstellung in einer Produktionsumgebung durchführen, ist es wichtig, alle Änderungen zu bestätigen, die in Ihrer Umgebung vorgenommen werden.

Resource Manager stellt den Was-wäre-wenn-Vorgang bereit, den Sie für Ihre Bicep-Datei innerhalb der Pipelinephase ausführen können:

Sie können den Azure CLI-Befehl az deployment group what-if in Ihrer Pipelinedefinition verwenden, um den Was-wäre-wenn-Schritt auszuführen:

stages:

- stage: Preview
  jobs: 
  - job: Preview
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'MyServiceConnection'
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          az deployment group what-if \
            --resource-group $(ResourceGroupName) \
            --template-file deploy/main.bicep

Der Was-wäre-wenn-Vorgang nimmt keine Änderungen an Ihrer Umgebung vor. Stattdessen werden die erstellten Ressourcen, die aktualisierten Ressourceneigenschaften und die gelöschten Ressourcen beschrieben.

Der Was-wäre-wenn-Modus zeigt manchmal an, dass sich eine Ressource ändern wird, auch wenn tatsächlich keine Änderung erfolgt. Das Feedback wird als Rauschen bezeichnet. Wir arbeiten daran, diese Probleme zu reduzieren. Hier können Sie Probleme melden.

Nachdem die Ausgabe des Was-wäre-wenn-Vorgangs angezeigt wird, können Sie entscheiden, ob Sie mit der Bereitstellung fortfahren möchten. In diesem Schritt überprüft in der Regel eine Person die Ausgabe des Befehls „Was-wäre-wenn“ und trifft dann eine Entscheidung darüber, ob die ermittelten Änderungen sinnvoll sind. Wenn ein Prüfer entscheidet, dass die Änderungen angemessen sind, können sie die Pipelineausführung manuell genehmigen.

Umgebungen

In Azure Pipelines stellt eine Umgebung den Ort dar, an dem Ihre Lösung bereitgestellt wird. Umgebungen bieten Features, die Ihnen bei der Arbeit mit komplexen Bereitstellungen helfen. In einem nachfolgenden Modul erfahren Sie mehr über Umgebungen und deren Features. Vorerst konzentrieren wir uns auf die Möglichkeit, Ihrer Pipeline manuelle Genehmigungen hinzuzufügen.

Wie Sie bereits wissen, verwenden Sie Aufträge, um eine Abfolge von Schritten innerhalb einer Pipelinephase zu definieren. Wenn Sie Umgebungen in Ihre Pipeline einschließen, müssen Sie einen besonderen Auftragstyp verwenden, der als Bereitstellungsauftrag bezeichnet wird. Ein Bereitstellungsauftrag ähnelt einem normalen Auftrag, bietet jedoch einige zusätzliche Funktionen. Dazu zählt das Definieren der Umgebung, die für den Bereitstellungsauftrag verwendet wird:

variables:
  - name: deploymentDefaultLocation
    value: westus3

stages:

- stage: Preview
  jobs:
  - job: Preview
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'MyServiceConnection'
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          az deployment group what-if \
            --resource-group $(ResourceGroupName) \
            --template-file deploy/main.bicep

- stage: Deploy
  jobs:
    - deployment: Deploy
      environment: MyAzureEnvironment
      strategy:
        runOnce:
          deploy:
            steps:
            - checkout: self

            - task: AzureResourceManagerTemplateDeployment@3
              name: Deploy
              displayName: Deploy to Azure
              inputs:
                connectedServiceName: 'MyServiceConnection'
                location: $(deploymentDefaultLocation)
                resourceGroupName: $(ResourceGroupName)
                csmFile: deploy/main.bicep

Beachten Sie, dass in der YAML-Definition für einen Bereitstellungsauftrag einige wichtige Unterschiede von einem normalen Auftrag bestehen:

• Ein Bereitstellungsauftrag beginnt nicht mit dem Wort job, sondern wird als deployment definiert.
• Das environment-Schlüsselwort gibt den Namen der Zielumgebung an. Im vorherigen Beispiel wird die Bereitstellung für eine Umgebung mit dem Namen MyAzureEnvironment nachverfolgt.
• Das strategy-Schlüsselwort gibt an, wie Azure Pipelines die Bereitstellungsschritte ausführt. Bereitstellungsstrategien unterstützen komplexe Bereitstellungsprozesse, insbesondere wenn Sie über mehrere Produktionsumgebungen verfügen. In diesem Modul verwenden Sie die runOnce Bereitstellungsstrategie. Diese Strategie verhält sich ähnlich wie die anderen Aufträge, die Sie bereits kennen.

Phasenüberprüfungen und Genehmigungen

Nachdem Sie eine Umgebung erstellt haben, können Sie Überprüfungen definieren. Überprüfungen werden verwendet, um Bedingungen zu überprüfen, die erfüllt sein müssen, bevor eine Pipeline die Umgebung verwenden kann. Eine Genehmigung ist eine Form der Überprüfung, die erfordert, dass ein Mensch manuell genehmigt.

Überprüfungen werden in der Umgebung und nicht in der Pipeline definiert. Autor*innen der YAML-Pipelinedatei können diese Überprüfungen und Genehmigungen nicht entfernen oder hinzufügen. Nur die Administrator*innen einer Umgebung können die Überprüfungen und Genehmigungen verwalten.

In vielen Organisationen ist die besitzende Person einer Umgebung in Azure Pipelines die Person, die für die Umgebung verantwortlich ist, in der die Bereitstellung erfolgt. Mit Überprüfungen und Genehmigungen kann dafür gesorgt werden, dass die richtigen Mitarbeiter*innen am Bereitstellungsprozess beteiligt sind.

Wie funktionieren Überprüfungen und Genehmigungen?

Genehmigungen und Überprüfungen werden unmittelbar vor Beginn einer Pipelinephase ausgewertet. Wenn Azure Pipelines eine Pipelinephase ausführen wird, prüft es alle Pipeline-Ressourcen, die in der Phase verwendet werden, einschließlich Umgebungen. Umgebungen können Überprüfungen aufweisen, die erfüllt werden müssen.

Eine Genehmigung ist ein Überprüfungstyp. Wenn Sie eine Genehmigungsprüfung konfigurieren, weisen Sie einen oder mehrere Prüfer zu, die die Fortsetzung der Pipeline genehmigen müssen.

Azure Pipelines bietet auch andere Arten von Prüfungen. Sie können beispielsweise eine API aufrufen, um benutzerdefinierte Logik auszuführen, die Geschäftszeiten zu steuern, in denen eine Phase ausgeführt werden kann, und sogar Azure Monitor abfragen, um sicherzustellen, dass eine Bereitstellung erfolgreich war. In diesem Modul werden nur Genehmigungsprüfungen behandelt, aber die Modulzusammenfassung enthält Links zu weiteren Informationen zu Prüfungen.

Nachdem die Pipeline gestartet wurde und eine Phase erreicht hat, für die eine Genehmigungsüberprüfung erforderlich ist, wird die Pipelineausführung angehalten. Alle Prüfer, die als Genehmigende festgelegt wurden, werden eine Nachricht in Azure DevOps und per E-Mail gesendet.

Genehmigende Personen können die Pipelineprotokolle überprüfen, z. B. die Änderungen, die der Was-wäre-wenn-Vorgang erkennt. Basierend auf den angezeigten Informationen genehmigen sie die Änderung oder lehnen sie ab. Wenn sie die Änderung genehmigen, nimmt die Pipeline den Betrieb wieder auf. Wenn sie ablehnen oder nicht innerhalb eines konfigurierbaren Fristrahmens reagieren, schlägt die Phase fehl.

Wichtigkeit bewährter Methoden

Die Umgebungsfunktion in Azure Pipelines bietet Ihnen die Möglichkeit, Ihre Bereitstellungen mit einer Umgebung zu verknüpfen. Die Bereitstellung übernimmt dann die Überprüfungen und Genehmigungen, die vom Besitzer der Umgebung definiert wurden. Es ist jedoch nicht erforderlich, dass neue Pipelines Umgebungen verwenden.

Sie und Ihre Organisation müssen bewährte Methoden für die Überprüfung der Pipelinedefinitionen einführen. Sie können Ihr Repository beispielsweise so konfigurieren, dass Pull Requests bei jeder Änderung am Mainbranch anhand der Schutzrichtlinien für Branches überprüft werden müssen. Weitere Informationen zu diesem Konzept finden Sie in einem späteren Modul.

Sie können auch Überprüfungen und Genehmigungen zu Dienstverbindungen hinzufügen, die sicherstellen, dass die Genehmigung abgerufen wird, bevor eine Bereitstellung die Anmeldeinformationen eines Dienstprinzipals verwenden kann. Die Genehmigungen würde sich jedoch auch auf die Fähigkeit Ihrer Pipeline auswirken, eine Preflightüberprüfung und den Was-wäre-wenn-Vorgang auszuführen, da diese auch eine Dienstverbindung erfordern.

Sie können für die Was-wäre-wenn-Phase eine andere separate Dienstverbindung mit einem eigenen Dienstprinzipal verwenden. Für den Dienstprinzipal, der für die Preflight- und Überprüfungsphasen verwendet wird, muss eine benutzerdefinierte Azure-Rolle definiert sein, damit dieser über die erforderlichen Mindestberechtigungen verfügt.