Testen Ihrer Ressourcen nach der Bereitstellung

Aufgrund der Überprüfungen und Vorschauansicht Ihrer Bicep-Bereitstellung können Sie mit recht hoher Sicherheit davon ausgehen, dass die Bereitstellung Ihrer Bicep-Dateien erfolgreich verlaufen wird. Doch nach der Bereitstellung ist Ihre Arbeit noch nicht erledigt. Sie sollten nach Abschluss der Bereitstellung überprüfen, ob sie wie erwartet funktioniert.

In dieser Lerneinheit erfahren Sie mehr über Tests, die Sie nach Abschluss der Bereitstellung durchführen können. Außerdem lernen Sie, wie Sie einen Rollback für Ihre Bereitstellung ausführen, wenn das Bereitstellungsergebnis nicht Ihren Erwartungen entspricht.

Ausführen von Feuerproben und Negativtests

Wenn Sie Ressourcen in einer Bicep-Datei definieren, geht es nicht nur darum, Ressourcen in Azure zu erstellen. Sie möchten Ihrer Organisation auch einen Mehrwert bieten und gleichzeitig die Anforderungen erfüllen. Wenn Sie Ihre Bicep-Dateien überprüfen und eine Vorschau anzeigen, steigt Ihre Gewissheit, dass die Ressourcendefinitionen gültig sind. Sie wissen jedoch nicht unbedingt, ob die Ressourcen die gewünschten Aktionen ausführen.

Stellen Sie sich beispielsweise vor, Sie stellen einen neuen logischen Azure SQL-Server mithilfe einer Bicep-Bereitstellungspipeline bereit. Ihre Bicep-Definition für den Server ist gültig, sodass sie die Linter- und Preflightüberprüfungsphasen besteht. Der Was-wäre-wenn-Befehl zeigt, dass ein Server erstellt wird, was auch Ihren Erwartungen entspricht. Die Bereitstellung wird ebenfalls erfolgreich abgeschlossen. Am Ende des Bereitstellungsprozesses ist es dennoch möglich, dass der Datenbankserver nicht funktioniert bzw. einsatzbereit ist. Das kann unter anderem diese Gründe haben:

• Sie haben keine Firewallregeln konfiguriert, die Netzwerkdatenverkehr an Ihren Server zulassen.
• Sie haben die Microsoft Entra-Authentifizierung auf Ihrem Server aktiviert, obwohl Sie es nicht sollten oder umgekehrt.

Selbst wenn Sie nur einfache Bicep-Dateien bereitstellen, sollten Sie überlegen, wie Sie überprüfen können, ob die von Ihnen bereitgestellten Ressourcen tatsächlich funktionieren und Ihre Anforderungen erfüllen. Hier finden Sie Beispiele für die Anwendung dieser Überprüfung:

• Wenn Sie eine Website bereitstellen, versuchen Sie, die Webanwendung über Ihre Pipeline zu erreichen. Vergewissern Sie sich, dass Ihre Pipeline erfolgreich eine Verbindung mit der Website herstellt und einen gültigen Antwortcode empfängt.
• Versuchen Sie bei der Bereitstellung eines CDN (Content Delivery Network), über dieses eine Verbindung mit einer Ressource herzustellen. Stellen Sie sicher, dass die Pipeline erfolgreich eine Verbindung mit dem CDN herstellt und einen gültigen Antwortcode empfängt.

Diese Tests werden manchmal als Feuerproben für die Infrastruktur bezeichnet. Die Feuerprobe ist ein einfacher Test, der entwickelt wurde, um größere Probleme in Ihrer Bereitstellung aufzudecken.

Es ist auch eine gute Idee, Negativtests durchzuführen. Negative Tests helfen Ihnen, zu bestätigen, dass sich Ihre Ressourcen nicht auf unerwünschte Weise verhalten. Wenn Sie beispielsweise einen virtuellen Computer bereitstellen, ist es eine bewährte Methode, Azure Bastion zu verwenden, um eine sichere Verbindung mit dem virtuellen Computer herzustellen. Sie können Ihrer Pipeline einen Negativtest hinzufügen, um sich davon zu überzeugen, dass Sie mithilfe von Remotedesktopverbindung oder SSH keine direkte Verbindung mit einem virtuellen Computer herstellen können.

Ausführen von Tests aus Azure Pipelines

Es gibt viele Möglichkeiten, Tests in Ihrer Pipeline auszuführen. In diesem Modul verwenden Sie Pester, ein Open-Source-Tool, das Tests ausführt, die über PowerShell geschrieben wurden. Sie können ein anderes Testframework verwenden oder sogar Ihre Tests ohne ein Testtool ausführen. Ein weiteres interessantes Testtool ist beispielsweise PSRule für Azure, das eine Reihe vordefinierter Regeln und Tests für Azure enthält. Es kann die Validierung für Ihre Vorlagen und auch Tests für Ihre bereitgestellten Azure-Ressourcen ausführen. Es gibt einen Link zu PSRule in der Modulzusammenfassung.

Wenn Sie ein unterstütztes Testframework verwenden, versteht Azure Pipelines die Ergebnisse der einzelnen Tests. Es zeigt die Testergebnisse zusammen mit der Pipelineausführung an und verfolgt den Verlauf jedes einzelnen Tests im Zeitverlauf. In der nächsten Übung erfahren Sie, wie Sie Azure Pipelines mit Feuerproben für die Infrastruktur verwenden können.

Übergeben von Daten zwischen Schritten und Phasen

Wenn Sie Ihre Pipeline in Phasen unterteilen, müssen Sie manchmal Daten zwischen diesen Phasen übergeben. Eine Phase kann beispielsweise eine Azure-Ressource erstellen, mit der eine andere Phase arbeiten muss. Um Daten übergeben zu können, muss die zweite Phase den Namen der erstellten Ressource kennen. In der folgenden Übung muss beispielsweise die Feuerprobephase auf die Ressourcen zugreifen, die von der Bereitstellungsphase bereitgestellt werden.

Ihre Bicep-Datei stellt die Ressourcen so bereit, dass sie auf die Ressourceneigenschaften zugreifen und sie als Bereitstellungsausgaben veröffentlichen kann. Sie können auf eine Bereitstellungsausgabe in Ihrer Pipeline zugreifen. In Azure Pipelines gibt es eine spezielle Syntax für die Veröffentlichung von Variablen, um diese phasenübergreifend verfügbar zu machen.

Zunächst müssen Sie eine Ausgabevariable für eine Pipelinephase veröffentlichen. Um die Variable auszugeben, schreiben Sie eine speziell formatierte Zeichenfolge in das Pipelineprotokoll, das Azure Pipelines lesen können. Im folgenden Beispiel wird eine Variable mit dem Namen myVariable auf den Wert myValue festgelegt:

echo "##vso[task.setvariable variable=myVariable;isOutput=true]myValue"

Azure Pipelines liest und interpretiert die Zeichenfolge aus dem Pipelineprotokoll und macht den Wert der Variablen als Ausgabe verfügbar. Sie können diesen Wert mit weiteren Skripts kombinieren, um den Wert einer Bicep-Bereitstellungsausgabe als Ausgabevariable für eine Pipelinephase zu veröffentlichen. Auf die Skripterstellung wird in der nächsten Übung eingegangen.

Zweitens müssen Sie die Variable dann für den Auftrag Ihrer Feuerprobenphase verfügbar machen. Sie definieren eine Variable für den Auftrag und verwenden eine andere speziell formatierte YAML-Zeichenfolge:

- stage: SmokeTest
  jobs:
  - job: SmokeTest
    variables:
      myVariable: $[ stageDependencies.DeployStage.DeployJob.outputs['DeployJob.DeployStep.myVariable'] ]

Nun können alle Schritte innerhalb des Feuerprobenauftrags auf den Wert myVariable und auf jede andere Variable zugreifen, indem sie die Syntax $(myVariable) verwenden. Sie verwenden diese Variable in der nächsten Übung.

Andere Testtypen

Funktionstests und Integrationstests werden häufig verwendet, um zu überprüfen, ob sich die bereitgestellten Ressourcen wie erwartet verhalten. Beispielsweise kann ein Integrationstest eine Verbindung mit Ihrer Website herstellen, eine Testtransaktion übermitteln und dann warten, um zu bestätigen, dass die Transaktion erfolgreich abgeschlossen wurde. Mithilfe von Integrationstests können Sie die Lösung testen, die Ihr Team erstellt, sowie die Infrastruktur, in der sie ausgeführt wird. In einem zukünftigen Modul erfahren Sie, wie Sie diese Testtypen zu Ihrer Pipeline hinzufügen können.

Es ist auch möglich, andere Arten von Tests aus einer Bereitstellungspipeline auszuführen, einschließlich Leistungstests und Sicherheitspenetrationstests. Diese Tests sind nicht Gegenstand des Moduls, können aber einen Mehrwert für einen automatisierten Bereitstellungsprozess schaffen.

Rollback und Rollforward

Angenommen, Ihre Pipeline stellt Ihre Ressourcen erfolgreich bereit, aber Ihre Tests schlagen fehl. Wie sollten Sie dann vorgehen?

Weiter oben in diesem Modul haben Sie gelernt, dass Sie mit Azure Pipelines Rollbackphasen erstellen können, die ausgeführt werden, wenn eine vorherige Phase fehlschlägt. Sie können diesen Ansatz verwenden, um eine Rollbackphase zu erstellen, wenn die Testphase ein unerwartetes Ergebnis meldet. Sie können ihre Änderungen auch manuell zurücksetzen oder die gesamte Pipeline erneut ausführen, wenn Sie der Meinung sind, dass der Fehler durch ein temporäres Problem verursacht wurde, das seitdem behoben wurde.

Es ist oft schwierig, die Schritte zu erarbeiten, die eine Rollbackphase ausführen sollte. Im Allgemeinen sind Bicep-Bereitstellungen komplex, und es ist schwierig, Änderungen zurückzusetzen. Ein Rollback ist besonders schwierig, wenn Ihre Bereitstellung andere Komponenten enthält.

Angenommen, Ihre Pipeline stellt eine Bicep-Datei bereit, die eine Azure SQL-Datenbank definiert, und fügt dann der Datenbank einige Daten hinzu. Sollen die Daten gelöscht werden, wenn für Ihre Bereitstellung ein Rollback ausgeführt wird? Soll auch die Datenbank entfernt werden? Es ist nicht einfach, die Auswirkungen von Fehlern und Rollbacks auf Ihre ausgeführte Umgebung vorherzusagen.

Aus diesem Grund bevorzugen viele Organisationen die Ausführung von Rollforward, was bedeutet, dass sie schnell die Ursache des Fehlers beheben und dann erneut bereitstellen. Indem Sie einen qualitativ hochwertigen automatisierten Bereitstellungsprozess erstellen und alle bewährten Methoden verfolgen, die Sie in diesen Lernpfaden gelernt haben, können Sie Probleme schnell beheben und Ihre Bicep-Dateien erneut bereitstellen und gleichzeitig hohe Qualität beibehalten.