Grundlegendes zu Umgebungen
Bereitstellungsworkflows ermöglichen Ihnen das Automatisieren der Schritte in Ihrem Bereitstellungsprozess. Häufig müssen Sie die Schritte in mehreren separaten Umgebungen ausführen. In Ihrem Spielzeugunternehmen möchten Sie die Änderungen am Code überprüfen, bevor Sie die Änderungen in Ihrer Produktionsumgebung bereitstellen.
In dieser Lerneinheit erfahren Sie, wie Umgebungen in GitHub Actions Ihnen helfen, Ihren eigenen Prozess zu unterstützen.
Warum verfügen Sie über mehrere Umgebungen?
Bereitstellungsprozesse nehmen Änderungen an Ihren Azure-Ressourcen vor, einschließlich der verwendeten Ressourcen. Das Ändern von Ressourcen birgt ein gewisses Risiko, da sich die von Ihnen bereitgestellten Änderungen möglicherweise nicht wie erwartet verhalten. Möglicherweise stellen Sie sogar fest, dass die Änderungen das aktuelle Setup unterbrechen.
Zum Minimieren des Risikos von Problemen ist es eine bewährte Methode, Ihre Änderungen auf sichere Weise auszuprobieren, bevor Sie sie in Ihrer Produktionsumgebung bereitstellen. Sie minimieren das Risiko, indem Sie die Änderungen in einer Nicht-Produktionsumgebung bereitstellen.
Viele Organisationen richten mehrere Nicht-Produktionsumgebungen ein, in denen sie ihre Änderungen schrittweise bereitstellen, bevor sie in der Produktion freigegeben werden. Jede Nicht-Produktionsumgebung erfüllt einen bestimmten Zweck und verfügt häufig über bestimmte Qualitätsprüfpunkte, deren Anforderungen erfüllt werden müssen, um mit der nächsten Umgebung fortzufahren. Wenn etwas misslingt, z. B. ein Test nicht erfolgreich ist, wird die Bereitstellung beendet. Während Ihre Bereitstellung die einzelnen Umgebungen durchläuft, wächst Ihr Vertrauen in die Änderungen.
Zu den gängigen Umgebungen gehören:
Entwicklung:Eine Entwicklungsumgebung wird in der Regel von Entwicklern verwendet, um ihre Änderungen zu testen und ihre Arbeit schnell zu wiederholen.
Entwicklungsumgebungen verfügen häufig über minimale Kontrollen, sodass Teammitglieder leicht Ideen ausprobieren können. Sie können eine Entwicklungsumgebung verwenden, um eine bestimmte Konfigurationseinstellung für eine Ressource zu testen oder um zu erfahren, wie Sie eine neue Website mit einer Back-End-Datenbank auf sichere Weise einrichten können. Viele dieser Änderungen und Testversionen kommen in Ihrem Bereitstellungsprozess möglicherweise nicht weiter, da Sie Ideen, die nicht erfolgreich sind, nicht weiterverfolgen.
In einigen Teams können Sie sogar eine separate Entwicklungsumgebung für jedes Teammitglied einrichten, damit sie sich nicht gegenseitig im Weg stehen, während sie an neuen Features arbeiten.
Entwicklungsumgebungen werden manchmal auch als Sandboxumgebungen bezeichnet.
Test: Eine Testumgebung ist so konzipiert, dass manuelle oder automatisierte Tests für Ihre Änderungen ausgeführt werden.
Testumgebungen können in einem Continuous Integration-Prozess verwendet werden. Nachdem Sie eine Änderung in einer Testumgebung bereitgestellt haben, können automatisierte Tests dafür ausgeführt werden. Wenn alle automatisierten Tests erfolgreich sind, kann die Änderung sicher mit dem Mainbranch des Projekts zusammengeführt werden. Automatisierte Tests überprüfen in der Regel die Kernfunktionen des Systems sowie Richtlinienverstöße in den neu bereitgestellten Ressourcen.
Sie können auch dedizierte Testumgebungen für bestimmte Testtypen wie Leistungs- und Sicherheitstests erstellen.
Integration: Eine Integrationsumgebung kann Ihnen helfen, Integrationspunkte mit anderen Systemen zu testen.
Sie können End-to-End-Transaktionen in einer Integrationsumgebung simulieren. Diese Tests werden häufig automatisch ausgeführt, aber viele Organisationen führen auch manuelle Tests für diese Umgebung durch.
Integrationsumgebungen werden manchmal auch als SIT-Umgebungen (System Integration Test) bezeichnet.
Benutzerakzeptanztest: Eine Umgebung für den Benutzerakzeptanztest (User Acceptance Test, UAT) wird für die manuelle Überprüfung verwendet, in der Regel von Projektbeteiligten des Unternehmens und nicht von Entwicklern. Bei der manuellen Überprüfung geht jemand die Lösung durch und überprüft, ob sie sich wie erwartet verhält und die erforderlichen Geschäftsanforderungen erfüllt. Diese Person genehmigt dann die Änderungen, damit die Bereitstellung fortgesetzt werden kann.
Präproduktion: Eine Präproduktionsumgebung ist häufig ein Spiegel der Produktionsumgebung mit denselben Ressourcen-SKUs und der gleichen Konfiguration. Sie wird für die abschließende Überprüfung verwendet, wie sich die Produktionsbereitstellung während und nach der Anwendung der Änderung verhält. Mit der Umgebung kann auch überprüft werden, ob während der Produktionsbereitstellung Ausfallzeiten zu erwarten sind.
Präproduktionsumgebungen werden manchmal auch als Stagingumgebungen bezeichnet.
Produktion: Ihre Produktionsumgebung wird von Endbenutzern der Anwendung verwendet. Es ist Ihre Liveumgebung, die Sie schützen und so weit wie möglich in Betrieb halten möchten.
In einigen Organisationen verfügen Sie möglicherweise über mehrere Produktionsumgebungen. Beispielsweise können Produktionsumgebungen in verschiedenen geografischen Regionen oder für verschiedene Kundengruppen verwendet werden.
Demo: Ihr Team kann auch Demonstrationsumgebungen (Demoumgebungen) erstellen, um die Anwendung Endbenutzern zu zeigen, zur Verwendung beim Training oder für Vertriebsteams, um potenziellen Kunden bestimmte Funktionen zu zeigen. Möglicherweise verfügen Sie sogar über mehrere Demoumgebungen, die verschiedenen Zwecken dienen. Eine Demoumgebung ist häufig ein abgespecktes Replikat Ihrer Produktionsumgebung mit fingierten Kundendaten.
Umgebungen in Ihrer Organisation
Möglicherweise sehen Sie Variationen dieser Umgebungen. Einige Organisationen verwenden nur wenige Umgebungen, andere viele weitere. Die Anzahl und Art der Umgebungen, die Sie verwenden, hängen von der Lösung ab, die Sie bereitstellen, der Größe des Teams, das die Lösung entwickelt, und der Wichtigkeit der Workload.
Manchmal übernimmt eine einzelne Umgebung die Rolle mehrerer der zuvor aufgeführten Umgebungen. In anderen Fällen verfügen Sie möglicherweise über einen komplexen Workflow, der in mehreren Umgebungen bereitgestellt wird, in einigen gleichzeitig und in einigen nacheinander. Einige Organisationen löschen Umgebungen sogar automatisch oder heben ihre Bereitstellung automatisch auf, wenn sie nicht mehr verwendet werden, und stellen sie dann noch mal bereit, wenn sie in Zukunft benötigt werden.
Unabhängig davon, welche Umgebungen Ihre Organisation auswählt, besteht das Ziel darin, das Vertrauen in eine Änderung zu erhöhen, während sie Ihren Bereitstellungsworkflow durchläuft. Wenn eine Änderung Ihre Qualitätsanforderungen nicht erfüllt, möchten Sie die Bereitstellung dieser Änderung in allen nachfolgenden Umgebungen in der Kette beenden können.
In Ihrem Spielzeugunternehmen entscheiden Sie sich, mit einer Reihe von grundlegenden Umgebungen für Ihre Website zu beginnen. Zusätzlich zu Ihrer Produktionsumgebung erstellen Sie eine Nicht-Produktionsumgebung mit dem Namen Test:
Sie aktualisieren Ihren Workflow, um Ihren Bicep-Code in Ihrer Testumgebung bereitzustellen und einige grundlegende Tests für den Code durchzuführen. Wenn dabei keine Probleme auftreten, können Sie dann die Bereitstellung in Ihrer Produktionsumgebung ausführen.
Workflowumgebungen
GitHub Actions verfügt ebenfalls über das Konzept einer Umgebung. Sie erstellen eine GitHub Actions-Umgebung, um die Umgebung darzustellen, über die Sie in Azure verfügen. Wenn Sie Ihren Workflow in einer YAML-Datei definieren, können Sie Aufträge mit einer bestimmten Umgebung verknüpfen. Durch die Verwendung von Umgebungen erhalten Sie einige zusätzliche Features in Ihrem Workflow.
Schutzregeln
Für eine Umgebung in GitHub Actions können Schutzregeln konfiguriert werden. Bei jeder Bewegung der Umgebung in einem Auftrag in Ihrem Workflow wird von GitHub Actions sichergestellt, dass diese Regeln erfüllt wurden, bevor der Auftrag ausgeführt wird.
Sie können beispielsweise manuelle Überprüfungen in Ihrer Produktionsumgebung konfigurieren. Vor Beginn einer Produktionsbereitstellung erhält der angegebene Prüfer eine Benachrichtigung. Diese Person kann manuell überprüfen, ob Ihre Richtlinien und Verfahren erfüllt sind, bevor die Bereitstellung beginnt. Beispielsweise kann die genehmigende Person überprüfen, ob alles wie erwartet in der Präproduktionsumgebung funktioniert, bevor sie die Bereitstellung genehmigt.
Darüber hinaus können Sie eine automatisierte Überprüfung ausführen, um den Branch zu bestätigen, aus dem die Änderung kommt. Wenn sich die Änderung nicht im Mainbranch befindet, können Sie GitHub so konfigurieren, dass eine Bereitstellung der Änderung in Ihrer Produktionsumgebung verhindert wird.
Geheimnisse
GitHub Actions ermöglicht es Ihnen, Geheimnisse zu speichern, die nur mit einer bestimmten Umgebung verwendet werden können. Weitere Informationen zu Verwaltung von Geheimnissen erhalten Sie später in diesem Modul.
Bereitstellungsverlauf
GitHub Actions protokolliert den Verlauf der Bereitstellungen in einer Umgebung. Mit diesem Verlauf können Sie ganz einfach nachverfolgen, was in der Umgebung im Laufe der Zeit geschieht. Sie können sogar eine Bereitstellung bis zu einem Commit in Ihrem Repository nachverfolgen. Dieses Feature kann nützlich sein, wenn Sie ein Problem mit einer Bereitstellung haben und die Änderung identifizieren müssen, die zum Problem geführt hat.
Erstellen von Umgebungen
Sie können eine Umgebung über die GitHub-Weboberfläche erstellen.
Wenn ihr Workflow auf eine Umgebung verweist, die nicht vorhanden ist, wird diese von GitHub Actions automatisch erstellt. Dieses Feature kann sich auf die Sicherheit Ihres GitHub-Repositorys auswirken, da in der neuen Umgebung keine Schutzregeln konfiguriert sind. Daher sollten Sie idealerweise eine Umgebung selbst über die GitHub-Weboberfläche zu erstellen, damit Sie die volle Kontrolle über deren Sicherheit haben.
Verknüpfen eines Bereitstellungsauftrags mit einer Umgebung
In der Definition Ihres Bereitstellungsworkflows können Sie mithilfe der Eigenschaft environment auf eine Umgebung verweisen:
jobs:
deploy:
environment: Test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
In diesem Beispiel ist der Auftrag mit dem Namen deploy mit der Umgebung Test verknüpft.
Umgebungen und Verbindungen mit Azure
Wenn Sie mehrere Umgebungen verwenden, sollten Sie jede Umgebung von den anderen unabhängig machen. Beispielsweise sollte die Website Ihrer Entwicklungsumgebung nicht auf eine Datenbank in Ihrer Produktionsumgebung zugreifen können.
Dasselbe Prinzip gilt auch für den Bereitstellungsworkflow. Sie sollten für jede Umgebung separate Workloadidentitäten erstellen. Bei dieser Vorgehensweise eine weitere Schutzebene hinzugefügt, um sicherzustellen, dass sich Nicht-Produktionsbereitstellungen nicht auf Ihre Produktionsumgebung auswirken.
Workloadidentitäten sollten bestimmte Berechtigungen zugewiesen werden, damit Bereitstellungen nur für das Abonnement und die Ressourcengruppe durchgeführt werden können, die von der jeweiligen Umgebung verwendet werden:
Wichtig
Verwenden Sie für jede Umgebung, in der Sie eine Bereitstellung durchführen möchten, eine separate Workloadidentität. Erteilen Sie der Workloadidentität ausschließlich die Mindestberechtigungen, die für die Bereitstellung in der zugehörigen Umgebung benötigt werden.
Es ist auch eine gute Idee, Ihre Umgebungen in Azure zu trennen. Sie sollten mindestens eine separate Ressourcengruppe für jede Umgebung erstellen. In vielen Situationen ist es besser, separate Azure-Abonnements für jede Umgebung zu erstellen. Anschließend können Sie mehrere Ressourcengruppen innerhalb des Abonnements jeder Umgebung erstellen.
Wenden Sie Azure-Rollenzuweisungen an, damit Benutzer und Workloadidentitäten nur auf die Umgebungen zugreifen können, auf die sie wirklich Zugriff benötigen. Achten Sie darauf, den Zugriff auf Ihre Produktionsumgebung auf eine kleine Gruppe von Personen und die Workloadidentität zur Bereitstellung für diese Umgebung zu beschränken.
Verbundanmeldeinformationen für Umgebungen
Wenn sich Ihre Workloadidentität über Ihren Bereitstellungsworkflow mit Azure verbindet, verwendet sie Verbundanmeldeinformationen, um sich ohne Geheimnisse oder Schlüssel sicher zu authentifizieren. In den vorangegangenen Modulen dieses Lernpfads wurde mithilfe von Verbundanmeldeinformationen Zugriff auf Ihre Bereitstellungsworkflows gewährt, wenn diese aus dem Mainbranch Ihres Git-Repositorys bereitgestellt wurden.
Wenn Sie innerhalb Ihres Workflows eine Bereitstellung in einer Umgebung durchführen, müssen Sie Verbundanmeldeinformationen verwenden, die auf diese Umgebung beschränkt sind.
In diesem Modul umfasst Ihr Workflow mehrere Aufträge, von denen viele eine Verbindung mit Azure herstellen und eine Bereitstellung in Azure durchführen. Einige der Aufträge verwenden Umgebungen, andere nicht. Sie erstellen deshalb zwei Sätze mit Verbundanmeldeinformationen für jede Ihrer Workloadidentitäten: eine für die Umgebung und eine für den Mainbranch.