Vorschau und Genehmigung Ihrer Bereitstellung

5 Minuten

Sie haben nun mehr über Workflowaufträge erfahren und wissen, wie Sie einen Workflowauftrag hinzufügen können, um Ihren Bicep-Code zu überprüfen. Der nächste Schritt beim Aufbau von Vertrauen in Ihre Bereitstellung besteht darin, einen weiteren Auftrag 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 einem Workflow. Außerdem erfahren Sie mehr über das Hinzufügen von Schutzregeln für die Umgebung, 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 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.

Jedes Mal, wenn Ressourcen erstellt, aktualisiert oder gelöscht werden, besteht das Risiko, dass eine Änderung eintritt, die Sie nicht erwartet haben. Es ist eine bewährte Methode, einen zusätzlichen Schritt hinzuzufügen, um zu überprüfen, was 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, die an Ihrer Umgebung vorgenommen werden, zu bestätigen.

Resource Manager stellt den Was-wäre-wenn-Vorgang bereit, den Sie in Ihrer Bicep-Datei innerhalb des Workflowauftrags ausführen können:

Diagramm eines Workflows mit Linting-, Überprüfungs- und Vorschauaufträgen. Der Vorschauauftrag führt einen Was-wäre-wenn-Vorgang für Azure aus.

Die Aktion arm-deploy unterstützt das Auslösen des What-If-Vorgangs mithilfe der Eigenschaft additionalArguments:

jobs:
  preview:
     runs-on: ubuntu-latest
     needs: [lint, validate]
     steps: 
     - uses: azure/login@v1
       name: Sign in to Azure
       with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
     - uses: azure/arm-deploy@v1
       name: Run what-if
       with:
         failOnStdErr: false
         resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
         template: deploy/main.bicep
         parameters: >
           environmentType=${{ env.ENVIRONMENT_TYPE }}
         additionalArguments: --what-if

Der hervorgehobene Code entspricht der Ausführung der Bereitstellung mithilfe der Azure CLI, wobei das --what-if-Argument enthalten ist.

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-Vorgang zeigt mitunter eine Ressourcenänderung an, obwohl eigentlich keine Änderung vorgenommen wird. Diese Art von Ausgabe wird als Rauschen bezeichnet. Wir arbeiten an der Behebung dieses Problems, benötigen dazu jedoch Ihre Unterstützung. Melden Sie What-If-Probleme.

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 „what-if“ und trifft dann eine Entscheidung darüber, ob die ermittelten Änderungen sinnvoll sind. Wenn ein menschlicher Reviewer entscheidet, dass die Änderungen angemessen sind, kann er die Workflowausführung manuell genehmigen.

Weitere Informationen zum Was-wäre-wenn-Befehl finden Sie im Microsoft Learn-Modul Vorschau der Azure-Bereitstellungsänderungen mit Was-wäre-wenn.

Umgebungen

In GitHub Actions 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, Ihrem Workflow erforderliche Reviewer hinzuzufügen.

Sie erstellen eine Umgebung mithilfe der GitHub-Weboberfläche. Sie können Umgebungen erstellen, wenn Sie mit einem öffentlichen GitHub-Repository arbeiten oder wenn Sie ein GitHub Enterprise-Konto verwenden.

Nachdem Sie eine Umgebung erstellt haben, können Sie in allen Aufträgen in Ihrem Workflow darauf verweisen:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: 'Lint Bicep template'
      run: az bicep build --file deploy/main.bicep

  validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      with:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}
        deploymentMode: Validate

  deploy:
    runs-on: ubuntu-latest
    environment: MyAzureEnvironment
    needs: [lint, validate]
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      with:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

Hinweis

Wenn die Workloadidentität Ihres Bereitstellungsworkflows mit Resource Manager innerhalb einer Umgebung interagiert, benötigt sie Verbundanmeldeinformationen, die mit dem Namen der Umgebung konfiguriert sind. Weitere Informationen zu Umgebungen finden Sie in späteren Modulen. Wenn Sie die Übungen für dieses Modul ausführen, erstellen Sie die benötigten Verbundanmeldeinformationen.

Umgebungsschutzregeln

Nachdem Sie eine Umgebung erstellt haben, können Sie Schutzregeln definieren. Schutzregeln dienen dazu, Bedingungen zu überprüfen, die erfüllt sein müssen, bevor die Umgebung in einem Schritt verwendet werden kann. Die Schutzregel Erforderliche Reviewer ist eine Überprüfung, die eine Genehmigung durch eine Person erfordert.

Schutzregeln werden für die Umgebung und nicht für den Workflow definiert. Autoren der YAML-Workflowdatei können diese Schutzregeln nicht entfernen oder neue hinzufügen. Nur die Administrator*innen eines Repositorys und Kontobesitzer*innen können Umgebungen und deren Schutzregeln verwalten.

Mit Umgebungsschutzregeln kann dafür gesorgt werden, dass die richtigen Mitarbeiter*innen am Bereitstellungsprozess beteiligt sind.

Wie funktionieren Umgebungsschutzregeln?

Wenn Sie eine Umgebung einem Schritt zuordnen, werden die Schutzregeln der Umgebung unmittelbar vor Beginn des Schritts ausgewertet.

Ein erforderlicher Reviewer ist ein Schutzregeltyp. Wenn Sie eine Schutzregel für erforderliche Reviewer konfigurieren, weisen Sie mindestens einen GitHub-Benutzer zu, der die Fortsetzung Ihres Workflows genehmigen muss.

Umgebungen bieten noch weitere Arten von Schutzregeln. Beispielsweise können Sie die Git-Verzweigungen einschränken, die in bestimmten Umgebungen bereitgestellt werden können. In diesem Modul wird nur die Schutzregel für erforderliche Reviewer erörtert, in der Zusammenfassung werden aber Links zu weiteren Informationen zu anderen Schutzregeln bereitgestellt.

Nachdem Ihr Workflow gestartet wurde und einen Schritt erreicht, der einen Reviewer erfordert, wird die Workflowausführung angehalten. Alle Benutzer und Benutzerinnen, die als Reviewer festgelegt wurden, erhalten eine Nachricht in GitHub und per E-Mail.

Reviewer können die Workflowprotokolle überprüfen, z. B. die Änderungen, die der Was-wäre-wenn-Vorgang erkennt. Basierend auf diesen Informationen genehmigen sie die Änderung oder lehnen sie ab. Wenn sie die Änderung genehmigen, wird der Workflow fortgesetzt. Wenn sie sie ablehnen oder nicht innerhalb des Timeoutzeitraums antworten, führt der Auftrag zu einem Fehler.

Diagramm eines Workflows mit Linting-, Überprüfungs-, Vorschau- und Bereitstellungsaufträgen mit einer Genehmigungsüberprüfung vor dem Bereitstellungsauftrag

Wichtigkeit bewährter Methoden

Das Umgebungsfeature in GitHub ermöglicht Ihnen, Ihre Bereitstellungen mit einer Umgebung zu verknüpfen. Die Bereitstellung erbt dann die Schutzregeln, die von den Administrator*innen der Umgebung definiert werden. Es ist jedoch nicht erforderlich, dass neue Workflows Umgebungen verwenden.

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