Vorschau und Genehmigung Ihrer Bereitstellung
Sie haben nun die Pipelinephasen kennengelernt 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 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 eine Änderung eintritt, die Sie nicht erwartet haben. 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 in Ihrer Bicep-Datei innerhalb der Pipelinephase ausführen können:
Sie können den Azure CLI-Befehl az deployment group what-if
aus 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
Tipp
In diesem Modul wird zur Ausführung des Was-wäre-wenn-Vorgangs die Azure CLI verwendet. Wenn Sie eine eigene PowerShell-basierte Pipeline erstellen, können Sie das New-AzResourceGroupDeployment
-Cmdlet mit dem -Whatif
-Parameter oder das Get-AzResourceGroupDeploymentWhatIfResult
-Cmdlet verwenden.
Der Was-wäre-wenn-Vorgang nimmt keine Änderungen an Ihrer Umgebung vor. Stattdessen werden die erstellten oder gelöschten Ressourcen, die zu aktualisierenden Ressourceneigenschaften und die zu löschenden Ressourcen beschrieben.
Der Was-wäre-wenn-Vorgang zeigt mitunter eine Ressourcenänderung an, obwohl eigentlich keine Änderung vorgenommen wird. Das Feedback wird als Rauschen bezeichnet. Wir arbeiten daran, diese Probleme zu verringern, brauchen jedoch Ihre Hilfe, um diese Probleme zu 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 ein Mensch die Ausgabe des Was-wäre-wenn-Befehls und trifft dann eine Entscheidung darüber, ob die ermittelten Änderungen sinnvoll sind. Wenn ein menschlicher Prüfer entscheidet, dass die Änderungen angemessen sind, kann er die Pipelineausfü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 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 es in der YAML-Definition für einen Bereitstellungsauftrag einige wichtige Unterschiede zu einem normalen Auftrag gibt:
- Ein Bereitstellungsauftrag beginnt nicht mit dem Wort
job
, sondern wird alsdeployment
definiert. - Das
environment
-Schlüsselwort gibt den Namen der Zielumgebung an. Im vorherigen Beispiel wird die Bereitstellung für eine Umgebung mit dem NamenMyAzureEnvironment
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 wird die BereitstellungsstrategierunOnce
verwendet. 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 Überprüfung, die ein Mensch manuell erteilen muss.
Ü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 der*die Besitzer*in 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, werden alle Pipelineressourcen, die von der Phase verwendet werden, einschließlich Umgebungen, untersucht. 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 Benutzer zu, die die Fortsetzung Ihrer Pipeline genehmigen müssen.
Azure Pipelines bietet auch andere Überprüfungen. Beispielsweise können Sie eine API aufrufen, um eine benutzerdefinierte Logik auszuführen, die Geschäftszeiten 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 Genehmigungsüberprüfungen behandelt. Links zu weiteren Informationen zu Überprüfungen werden in der Zusammenfassung bereitgestellt.
Hinweis
Für Agentpools und Dienstverbindungen können auch Überprüfungen konfiguriert sein. Sie können auch einen speziellen Schritt verwenden, der als manuelle Genehmigungsaufgabe bezeichnet wird. In diesem Modul konzentrieren wir uns jedoch auf Umgebungen und die damit verbundenen Überprü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 Benutzer, die als genehmigende Personen festgelegt wurden, erhalten eine Nachricht in Azure DevOps und per E-Mail.
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, wird die Pipeline fortgesetzt. Wenn sie ablehnen oder nicht innerhalb eines konfigurierbaren Fristrahmens reagieren, schlägt die Phase fehl.
Wichtigkeit bewährter Methoden
Das Umgebungsfeature in Azure Pipelines ermöglicht es Ihnen, Ihre Bereitstellungen mit einer Umgebung zu verknüpfen. Die Bereitstellung erbt dann die Genehmigungen und Überprüfungen, die vom Besitzer bzw. der Besitzerin der Umgebung definiert werden. 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 eine andere, separate Dienstverbindung für die Was-wäre-wenn-Phase 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.