Testen und Bereitstellen der konvertierten Vorlage

Abgeschlossen

Nachdem Sie Ihre Bicep-Datei während der Umgestaltungsphase verbessert haben, müssen Sie Ihre Datei testen und in Ihrer Azure-Umgebung bereitstellen. Die vierte und fünfte Phase des empfohlenen Workflows sind die Testphase und die Bereitstellungsphase:

Diagram that shows the test and deploy phases of the recommended workflow for migrating Azure resources to Bicep.

Der Hauptfokus dieser beiden Phasen besteht darin, Ihre Bicep-Datei mit den verfügbaren Tools zu testen und Ihre Datei dann in Ihrer Azure-Umgebung bereitzustellen.

Testphase

In der Testphase der Migration Ihrer Ressourcen zu Bicep besteht das Ziel darin, die Integrität Ihrer migrierten Vorlagen zu überprüfen und eine Testbereitstellung durchzuführen.

Die Testphase besteht aus zwei Schritten, die Sie in der folgenden Reihenfolge ausführen:

  1. Ausführen des Was-wäre-wenn-Vorgangs der ARM-Vorlagenbereitstellung.
  2. Durchführen einer Testbereitstellung

Diagram that shows a Bicep file being tested and deployed to Azure.

Der Was-wäre-wenn-Vorgang liefert eine Vorschau der Änderungen, die mit der Bereitstellung Ihrer Bicep-Datei erfolgen. Verwenden Sie eine Testbereitstellung, um Ihre ursprünglichen Ressourcen mit den neu bereitgestellten Ressourcen zu vergleichen.

Was ist der Was-wäre-wenn-Vorgang der ARM-Vorlagenbereitstellung?

Wenn Sie neue Ressourcen bereitstellen oder vorhandene Ressourcen ändern, können Sie Breaking Changes in Ihre Umgebungen einführen. Ihre Bereitstellung kann vorhandene Ressourcen ändern oder löschen, falsch konfigurierte neue Ressourcen erstellen oder die Gesamtfunktionalität Ihrer Anwendung beeinträchtigen.

Sie können den ARM-Was-wäre-wenn-Vorgang der Vorlagenbereitstellung verwenden, um die konvertierten Vorlagen vor der Bereitstellung zu überprüfen. Dabei wird der aktuelle Zustand Ihrer Umgebung mit dem gewünschten Zustand verglichen, der in der Vorlage definiert ist. Das Tool gibt die Liste der Änderungen aus, die auftreten, ohne die Änderungen auf Ihre Umgebung anzuwenden. Dieser Prozess kann dazu beitragen, Ihr Vertrauen in Ihre Bereitstellungen zu erhöhen. Sie können Was-wäre-wenn sowohl mit inkrementellen als auch mit vollständigen Bereitstellungen verwenden. Auch wenn Sie ihre Vorlage im inkrementellen Modus bereitstellen möchten, empfiehlt es sich, Ihren Was-wäre-wenn-Vorgang im vollständigen Modus auszuführen. Wenn Sie den Was-wäre-wenn-Vorgang ausführen, können Sie alle Ressourcen identifizieren, die Sie versehentlich aus der Vorlage weggelassen haben.

Hinweis

Der Was-wäre-wenn-Vorgang listet möglicherweise einige Ressourceneigenschaften als gelöscht auf, obwohl sie sich nicht ändern. Diese Ergebnisse werden als Rauschen betrachtet.

Testbereitstellung

Bevor Sie Ihre konvertierte Bicep-Vorlage in der Produktion verwenden, sollten Sie mehrere Testbereitstellungen ausführen. Wenn Sie über mehrere Umgebungen (Produktion, Entwicklung, Test) verfügen, sollten Sie versuchen, Ihre Vorlage zunächst in einer Ihrer Nicht-Produktionsumgebungen bereitzustellen. Vergleichen Sie nach der Bereitstellung die ursprünglichen Ressourcen mit den neuen Ressourcenbereitstellungen auf Konsistenz.

Tipp

Wenn Sie keinen Zugriff auf eine Nicht-Produktionsumgebung haben, um Ihre Bereitstellung zu testen, stellen Sie Ihre Bicep-Vorlage stattdessen in einer neuen Umgebung bereit.

Bereitstellungsphase

In der Bereitstellungsphase der Migration Ihrer Ressourcen zu Bicep besteht das Ziel darin, Ihre endgültige Bicep-Datei in der Produktion bereitzustellen. Vor der Bereitstellung in der Produktion sollten Sie einige Dinge berücksichtigen.

Die Bereitstellungsphase besteht aus vier Schritten, die Sie in der folgenden Reihenfolge ausführen:

  1. Vorbereiten eines Rollbackplans.
  2. Ausführen des Was-wäre-wenn-Vorgangs für die Produktion.
  3. Stellen Sie die Bicep-Datei manuell bereit.
  4. Ausführen von Feuerproben

Diese Schritte helfen Ihnen bei der Vorbereitung auf mögliche Probleme mit Produktionsbereitstellungen.

Diagram that shows a Bicep file being deployed to Azure.

Vorbereiten eines Rollbackplans

Die Möglichkeit zur Wiederherstellung nach einer fehlerhaften Bereitstellung ist entscheidend. Verbringen Sie Zeit mit der Entwicklung eines Rollbackplans, den Sie bei der Einführung von Breaking Changes in Ihre Umgebungen nutzen können. In Ihrem Plan sollte die Strategie für Geschäftskontinuität und Notfallwiederherstellung (BCDR) Ihrer Organisation berücksichtigt werden. Erfassen Sie die Ressourcentypen, die bereitgestellt werden, z. B. VMs, Web-Apps und Datenbanken. Sie sollten auch die Datenebene jeder Ressource berücksichtigen. Haben Sie eine Möglichkeit, einen virtuellen Computer und seine Daten wiederherzustellen? Haben Sie eine Möglichkeit, eine Datenbank nach dem Löschen oder die Daten aus einem Speicherkonto wiederherzustellen? Ein gut ausgearbeiteter Rollbackplan trägt dazu bei, die Downtime möglichst gering zu halten, wenn bei einer Bereitstellung Probleme auftreten.

Ausführen des Was-wäre-wenn-Vorgangs für die Produktion

Sie haben den Was-wäre-wenn-Vorgang bereits für Ihre anderen Umgebungen ausgeführt, um sicherzustellen, dass Ihre neue Bicep-Datei keine Breaking Changes verursacht. Bevor Sie Ihre endgültige Bicep-Datei in der Produktion bereitstellen, führen Sie den Was-wäre-wenn-Vorgang für Ihre Produktionsumgebung aus, stellen Sie sicher, dass Sie Produktionsparameterwerte verwenden, und erwägen Sie, die Ergebnisse zu dokumentieren.

Manuelle Bereitstellung

Wenn Sie die konvertierte Vorlage in einer Pipeline verwenden möchten, z. B. in Azure DevOps oder GitHub Actions, sollten Sie die Bereitstellung zuerst auf Ihrem lokalen Computer ausführen. Es ist besser, die Funktionalität der Vorlage zu überprüfen, bevor Sie die Vorlage Ihrer Produktionspipeline hinzufügen. Wenn Sie wissen, wie die Vorlage funktioniert, können Sie schnell reagieren, wenn ein Problem auftritt.

Ausführen von Feuerproben

Wenn Ihre Bereitstellung abgeschlossen ist, ist es eine gute Idee, eine Reihe von Feuerproben durchzuführen. Eine Feuerprobe ist eine einfache Überprüfung, ob Ihre Anwendung oder Ihr Workload funktioniert. Testen Sie beispielsweise, ob auf Ihre Web-App über normale Zugriffskanäle wie das öffentliche Internet oder über ein Unternehmens-VPN zugegriffen werden kann. Versuchen Sie bei Datenbanken, eine Datenbankverbindung herzustellen, und führen Sie eine Reihe von Abfragen aus. Melden Sie sich für VMs bei der VM an, und stellen Sie sicher, dass alle Dienste ausgeführt werden.