Bereitstellen kurzlebiger Umgebungen für Reviews

  • 6 Minuten

Das Linten Ihres Bicep-Codes gibt Ihnen einen Anhaltspunkt dafür, ob Ihre Azure-Bereitstellung wahrscheinlich erfolgreich sein wird. Es ist auch hilfreich, Ihren Bicep-Code irgendwo einzusetzen, um zu prüfen, wie Ihre Umgebung nach dem Mergen des Pull Requests und dem Abschluss der Bereitstellung aussehen wird.

In dieser Lerneinheit erfahren Sie, wie Sie Ihren Code innerhalb eines Pull Requests in einer temporären Umgebung bereitstellen.

Warum sollten Sie Ihren Code über einen Pull Request bereitstellen?

Wenn Sie einen Pull Request überprüfen, der Bicep-Code enthält, empfiehlt es sich, den Bicep-Code in einer realen Azure-Umgebung bereitzustellen. Auf diese Weise können Sie sicher sein, dass Ihre Änderungen in der Produktionsumgebung funktionieren. Wenn ein Problem auftritt, sollten Sie es schnell erkennen. Pull Requests bieten Ihnen eine großartige Möglichkeit, Probleme zu erkennen und hervorzuheben, da Sie sofortiges Feedback von Ihren Reviewern erhalten.

Sie haben sich jetzt an den Gedanken gewöhnt, Ihre Änderungen in einer oder mehreren Nicht-Produktionsumgebungen wie Test, Qualitätssicherung und Staging bereitzustellen, bevor Sie sie in Ihrer Produktionsumgebung bereitstellen. In vielen Unternehmen sind diese Umgebungen langlebig. Sie werden beim Rollout der Änderungen also aktualisiert, und die Umgebungen werden normalerweise nicht gelöscht.

Im Gegensatz dazu ist eine kurzlebige Umgebung eine Umgebung, die Sie dynamisch erstellen und eine, bei der Sie es in Kauf nehmen, dass sie gelöscht wird, wenn sie nicht mehr nützlich ist. Kurzlebige Umgebungen sind nur für eine kurze Zeitspanne gedacht (z. B. gerade für die Dauer der Überprüfung Ihrer Änderungen).

Kurzlebige Umgebungen sind eine gute Wahl, wenn Sie Umgebungen für Pull Requests bereitstellen, da Sie möglicherweise viele verschiedene Pull Requests gleichzeitig offen haben, die unterschiedliche Arten von Änderungen darstellen. Wenn mehrere Pull Requests geöffnet sind, bedeutet die Freigabe Ihrer langlebigen Nicht-Produktionsumgebungen, dass Sie jeweils nur eine Änderung in der Vorschau anzeigen können.

Erstellen kurzlebiger Umgebungen

Da Sie daran gewöhnt sind, Ihre Azure-Infrastruktur als Code zu erstellen, und Sie in die Erstellung Ihrer Bicep-Dateien zur Bereitstellung Ihrer Ressourcen investiert haben, können Sie dieselben Ressourcen zur Bereitstellung einer kurzlebigen Umgebung wiederverwenden. Sie können bei Bedarf sogar mehrere kurzlebige Umgebungen gleichzeitig bereitstellen. Sie müssen nur sicherstellen, dass Ihre Bereitstellungen ausreichend parametrisiert und generalisiert sind, sodass Sie problemlos unabhängige Umgebungen erstellen können. Beispielsweise müssen Sie sicherstellen, dass einige Azure-Ressourcen global eindeutige Namen erhalten, die nicht mit den Ressourcennamen in anderen kurz- oder langlebigen Umgebungen identisch sein können.

Kurzlebige Umgebungen bieten viele Vorteile:

  • Sie können neue Features und Funktionen sicher in einer isolierten Umgebung testen, und zwar ohne Auswirkungen auf Ihre anderen Produktions- oder Nicht-Produktionsworkloads.
  • Sie können Ihre Änderungen in Ihrem eigenen Branch anzeigen, sodass Sie Ihre Arbeit leicht Ihren Kollegen präsentieren oder Reviewern zugänglich machen können.
  • Sie können mehrere Teammitglieder gleichzeitig verschiedene Änderungen testen lassen, auch wenn diese nicht kompatibel sind.
  • Da Sie Ihre Bicep-Dateien regelmäßig ausführen müssen, können Sie mit kurzlebigen Umgebungen die Genauigkeit und Vollständigkeit Ihres Bicep-Codes und anderer Skripts kontinuierlich testen. So können Sie sicher sein, dass der Code in Ihrer Produktionsumgebung einwandfrei funktioniert.

In diesem Modul erstellen Sie kurzlebige Umgebungen, die Ihnen helfen, Vertrauen in die Änderungen in Pull Requests aufzubauen. Jede Person, die den Pull Request überprüft, kann auf die kurzlebige Umgebung zugreifen, einschließlich der neuen Ergänzungen und Aktualisierungen, bevor sie den Pull Request genehmigt und mergt.

Bereitstellung

Wenn Sie mit kurzlebigen Umgebungen arbeiten, ist es am besten, für jeden Pull Request, den Ihr Team erstellt, eine eigene Azure-Ressourcengruppe zu erstellen. Wenn ein Ersteller zwei verschiedene Pull Requests geöffnet hat, wird jeder seine eigene kurzlebige Umgebung besitzen. Dies trägt dazu bei, dass jede Änderung von den anderen Änderungen getrennt bleibt, und kann dazu beitragen, Verwechslungen oder versehentliches Überschreiben von Ressourcen zu vermeiden.

Diagramm mit für jeden Pull Request erstellter Ressourcengruppe

Damit dieser Ansatz funktioniert, muss Ihr Workflow zur Überprüfung von Pull Requests die Ressourcengruppen dynamisch erstellen. Ressourcengruppen erfordern eindeutige Namen, und Sie müssen auch in der Lage sein, die Ressourcengruppe leicht zu finden, um die Ressourcen zu testen sowie sie zu löschen, wenn Ihr Pull Request geschlossen wird. Um die Namen von Ressourcengruppen effektiv zu handhaben, können Sie die Nummer des Pull Requests im Namen der Ressourcengruppe verwenden. Die entsprechende Vorgehensweise wird in der nächsten Übung gezeigt.

Wenn es an der Zeit ist, die kurzlebige Umgebung zu löschen, ist es für Ihren Workflow ein Leichtes, die gesamte Ressourcengruppe zu finden und zu löschen. Alle Ressourcen, die in der kurzlebigen Umgebung verwendet werden, werden zur gleichen Zeit gelöscht.

Berechtigungen

Für das Erstellen von Ressourcengruppen sind Berechtigungen auf Abonnementebene erforderlich, und in der Regel muss der Workloadidentität Ihres Workflows die Rolle „Mitwirkender“ zugewiesen werden.

Es ist eine bewährte Methode, ein dediziertes Azure-Abonnement für kurzlebige Umgebungen zu verwenden. Auf diese Weise können Sie der Workloadidentität Ihres Workflows und Ihren Teammitgliedern Zugriff gewähren, ohne versehentlich Zugriff auf Ihre anderen Umgebungen zu ermöglichen.

Wichtig

Mitwirkende auf Abonnementebene verfügen über umfangreiche Berechtigungen. Daher müssen Sie sicherstellen, dass Sie über eine angemessene Governance rund um die Workloadidentität Ihres Workflows und die von ihr durchführbaren Änderungen verfügen. Mithilfe eines speziellen Abonnements für kurzlebige Umgebungen verringern Sie das Risiko für Ihre anderen Umgebungen.

Identität Ihres Workflows

Ihr Bereitstellungsworkflow verwendet eine Workloadidentität und Verbundinformationen, um sich bei Azure zu authentifizieren. Wenn Sie Pull Request-Überprüfungsworkflows verwenden, müssen Sie die Verbundinformationen so konfigurieren, dass sie mit Pull Requests funktionieren.

In einer vorherigen Übung in diesem Modul haben Sie einen Befehl zum Erstellen einer Verbundanmeldeinformation ausgeführt. Die Richtlinienzeichenfolge ähnelte der folgenden:

repo:my-github-user/my-repo:pull_request

pull_request gegen Ende der Zeichenfolge gibt an, dass die Verbundanmeldeinformation mit Pull Request-Überprüfungsworkflows funktioniert.

Kostenverwaltung

Wenn Sie dynamisch kurzlebige Umgebungen erstellen, besteht das Risiko, dass Ihre Azure-Kosten steigen. Wenn Ihr Team eine große Anzahl von Pull Requests geöffnet hat, könnten Sie eine große Anzahl von teuren Ressourcen in Azure bereitstellen.

Tipp

Wenn Ihr Team Pull Requests schnell schließt, sind höhere Kosten weniger problematisch, da eine kurzlebige Umgebung gelöscht wird, wenn der entsprechende Pull Request geschlossen wird.

Mithilfe eines dedizierten Azure-Abonnements können Sie auch die Kosten für Ihre kurzlebigen Umgebungen leicht überwachen. Außerdem können Sie abonnementweite Richtlinien anwenden, die die SKUs Ihrer kurzlebigen Ressourcen begrenzen und so Kostenüberschreitungen vermeiden helfen.

Darüber hinaus bietet Azure viele Möglichkeiten, die Ihnen helfen, die Kosten für kurzlebige Umgebungen zu kontrollieren, darunter:

  • Mit Microsoft Cost Management können Sie Budgets für ein Abonnement festlegen. Budgets lösen Benachrichtigungen aus, sodass Ihr Team weiß, dass sich die Kosten dem von Ihnen festgelegten Schwellenwert annähern.
  • Viele Azure-Ressourcentypen bieten kostengünstigere oder sogar kostenlose Tarife für Nicht-Produktionsworkloads. Überlegen Sie, ob Sie diese Tarife und SKUs verwenden können.
  • Einige Kunden können Azure Dev/Test-Preise für ihre Nicht-Produktionsabonnements in Anspruch nehmen.
  • Ressourcentags können Ihnen helfen, die Ressourcen zu identifizieren, die den einzelnen kurzlebigen Umgebungen zugeordnet sind, und die Kosten jeder kurzlebigen Umgebung zu berechnen.
  • Sie können Automatisierungsskripts erstellen, um Ihre kurzlebigen Ressourcen nach einer bestimmten Zeit zu löschen, oder beispielsweise sogar jede Nacht nach Geschäftsschluss.

Sie könnten auch erwägen, bestimmte Ressourcen zwischen kurzlebigen Umgebungen freizugeben. Ihr Bicep-Code kann z. B. viele Ressourcen definieren, von denen einige kostenintensiv sind oder deren Bereitstellung sehr lange dauern kann. Sie könnten eine freigegebene, langlebige Ressourcengruppe für alle Ihre Pull Requests erstellen, um die kostenintensiven Ressourcen freizugeben, und separate kurzlebige Ressourcengruppen für die anderen Ressourcen erstellen. Dieser Ansatz macht es jedoch schwierig und fehleranfällig, Ihre kurzlebigen Umgebungen zu verwalten und sie so voneinander zu trennen, dass sie während Ihres Überprüfungsprozesses hilfreich sind. Am besten vermeiden Sie diesen Ansatz, es sei denn, die Kosten für Ihre kurzlebigen Umgebungen werden zu hoch.