Verwalten von Umgebungen für die Bereitstellung

Informationen zu Umgebungen

Umgebungen werden verwendet, um ein allgemeines Bereitstellungsziel wie production, staging oder development zu beschreiben. Wenn ein GitHub Actions-Workflow in einer Umgebung bereitgestellt wird, wird die Umgebung auf der Hauptseite des Repositorys angezeigt. Weitere Informationen zum Anzeigen von Bereitstellungen für Umgebungen findest du unter Anzeigen des Bereitstellungsverlaufs.

Du kannst Umgebungen mit Schutzregeln und Geheimnissen konfigurieren. Wenn ein Workflowauftrag auf eine Umgebung verweist, wird der Auftrag erst dann gestartet, wenn alle Schutzregeln der Umgebung erfüllt sind. Ein Job kann außerdem erst dann auf Geheimnisse zugreifen, die in einer Umgebung definiert sind, wenn alle Regeln zum Schutz der Bereitstellung erfüllt sind.

Optional kannst du die Schutzregeln einer Umgebung umgehen und erzwingen, dass alle ausstehenden Aufträge, die auf die Umgebung verweisen, fortfahren. Weitere Informationen findest du unter Überprüfen von Bereitstellungen.

Regeln für den Bereitstellungsschutz

Regeln für den Bereitstellungsschutz legen fest, dass bestimmte Bedingungen erfüllt sein müssen, bevor ein Auftrag ausgeführt werden kann, der auf die Umgebung verweist. Du kannst Regeln für den Bereitstellungsschutz verwenden, um eine manuelle Genehmigung anzufordern, einen Auftrag zu verzögern oder die Umgebung auf bestimmte Branches zu beschränken. Du kannst auch benutzerdefinierte Schutzregeln von GitHub Apps erstellen und implementieren, um Drittanbietersysteme zum Steuern von Bereitstellungen zu verwenden, die auf in GitHub konfigurierte Umgebungen verweisen.

Drittanbietersysteme können Systeme für Einblicke, Change Management-Systeme, Systeme zur Sicherung der Codequalität oder andere manuelle Konfigurationen sein, mit denen du die Bereitschaft bewerten kannst, bevor Bereitstellungen sicher in Umgebungen eingeführt werden.

Erforderliche Reviewer

Verwende erforderliche Reviewer, um für Workflowaufträge, die auf die Umgebung verweisen, eine Genehmigung durch eine bestimmte Person oder ein Team als erforderlich festzulegen. Du kannst bis zu sechs Benutzer oder Teams als Reviewer auflisten. Die Reviewer müssen mindestens Lesezugriff auf das Repository haben. Nur einer der erforderlichen Reviewer muss den Auftrag genehmigen, damit er fortgesetzt werden kann.

Weitere Informationen zum Review von Aufträgen, die auf eine Umgebung mit erforderlichen Reviewern verweisen, findest du unter Überprüfen von Bereitstellungen.

Wartetimer

Verwende einen Wartetimer, um einen Auftrag für eine bestimmte Zeit zu verzögern, nachdem der Auftrag ausgelöst wurde. Die Zeit (in Minuten) muss eine ganze Zahl zwischen 1 und 43.200 (30 Tage) sein.

Bereitstellungsbranches

Mit Bereitstellungsbranches können Sie die Bereitstellung durch Branches in der Umgebung einschränken. Nachfolgend finden Sie die Optionen für Bereitstellungsbranches für eine Umgebung:

• Alle Branches: Alle Branches im Repository können Bereitstellungen in der Umgebung durchführen.

• ** Geschützte Branches**: Nur Branches mit aktivierten Branch-Schutzregeln können in der Umgebung Bereitstellungen durchführen. Wenn für keinen Branch im Repository Schutzregeln definiert sind, können alle Branches Bereitstellungen durchführen. Weitere Informationen zu Branch-Schutzregeln findest du unter Informationen zu geschützten Branches.

• Ausgewählte Branches: Nur Branches, die Ihrem vorgegebenen Namensmuster entsprechen, können in der Umgebung Bereitstellungen durchführen.

  Wenn Sie releases/* als Brereitstellungsbranch regel angeben, kann nur ein Branch, dessen Name mit releases/ beginnt, in der Umgebung Bereitstellungen durchführen. (Platzhalterzeichen sind keine Entsprechung für /. Damit Branches, die mit release/ beginnen und einen zusätzlichen einfachen Schrägstrich enthalten, eine Entsprechung darstellen, muss release/*/* verwendet werden). Wenn main als Branchregel hinzugefügt wird, kann auch ein Branch namens main Bereitstellungen in der Umgebung durchführen. Weitere Informationen zu den Syntaxoptionen für Bereitstellungsbranches sind in der RubyFile.fnmatch-Dokumentation zu finden.

Administratoren erlauben, konfigurierte Schutzregeln zu umgehen

Standardmäßig können Administrator*innen die Schutzregeln umgehen und Bereitstellungen in bestimmten Umgebungen erzwingen. Weitere Informationen finden Sie unter Überprüfen von Bereitstellungen.

Alternativ dazu kannst du Umgebungen so konfigurieren, dass die Umgehung von Schutzregeln für alle Bereitstellungen in der Umgebung nicht zugelassen ist.

Benutzerdefinierte Regeln für den Bereitstellungsschutz

Du kannst deine eigenen benutzerdefinierten Regeln für den Bereitstellungsschutz aktivieren, um Bereitstellungen mit Drittanbieterdiensten zu schützen. Sie können z. B. Dienste wie Datadog, Honeycomb und ServiceNow verwenden, um automatisierte Genehmigungen für Bereitstellungen in GitHub zu ermöglichen. Weitere Informationen findest du unter Erstellen von benutzerdefinierten Regeln für den Bereitstellungsschutz.

Nachdem benutzerdefinierte Regeln für den Bereitstellungsschutz erstellt und in einem Repository installiert wurden, kannst du diese für jede Umgebung im Repository aktivieren. Weitere Informationen zum Konfigurieren und Aktivieren von benutzerdefinierten Regeln für den Bereitstellungsschutz findest du unter Konfigurieren von benutzerdefinierten Regeln für den Bereitstellungsschutz.

Umgebungsgeheimnisse

Die in einer Umgebung gespeicherten Geheimnisse sind nur für Workflowaufträge verfügbar, die auf diese Umgebung verweisen. Wenn für die Umgebung eine Genehmigung erforderlich ist, kann ein Auftrag erst dann auf Umgebungsgeheimnisse zugreifen, wenn einer der erforderlichen Reviewer den Auftrag genehmigt hat. Weitere Informationen zu Geheimnissen findest du unter Verwenden von Geheimnissen in GitHub-Aktionen.

Umgebungsvariablen

Die in einer Umgebung gespeicherten Variablen sind nur für Workflowaufträge verfügbar, die auf diese Umgebung verweisen. Der Zugriff auf diese Variablen ist nur über den vars-Kontext möglich. Weitere Informationen finden Sie unter Speichern von Informationen in Variablen.

Erstellen einer Umgebung

Um eine Umgebung in einem Repository eines persönlichen Kontos zu konfigurieren, musst du der Repositorybesitzer sein. Um eine Umgebung in einem Organisationsrepository zu konfigurieren, musst du admin-Zugriff haben.

1. Navigieren Sie auf GitHub zur Hauptseite des Repositorys.

2. Wähle unter dem Namen deines Repositorys die Option Einstellungen aus. Wenn die Registerkarte „Einstellungen“ nicht angezeigt wird, wähle im Dropdownmenü die Option Einstellungen aus.

   

3. Klicke auf der linken Randleiste auf Umgebungen.

4. Klicke auf Neue Umgebung.

5. Gib einen Namen für die Umgebung ein, und klicke dann auf Umgebung konfigurieren. Bei Umgebungsnamen wird nicht zwischen Groß- und Kleinschreibung unterschieden. Ein Umgebungsname darf 255 Zeichen nicht überschreiten und muss innerhalb des Repositorys eindeutig sein.

6. Du kannst optional Personen oder Teams angeben, die Workflowaufträge mit Verwendung dieser Umgebung genehmigen müssen. Weitere Informationen findest du unter Erforderliche Reviewer.

   1. Wähle Required reviewers aus.

   2. Gib bis zu 6 Personen oder Teams ein. Nur einer der erforderlichen Reviewer muss den Auftrag genehmigen, damit er fortgesetzt werden kann.

   3. Klicke auf Schutzregeln speichern.

7. Gib optional die Zeitspanne an, die gewartet werden soll, bevor Workflowaufträge mit Verwendung dieser Umgebung fortgesetzt werden können. Weitere Informationen findest du unter Wartetimer.

   1. Wähle Wartetimer aus.
   2. Gib die gewünschte Wartezeit in Minuten ein.
   3. Klicke auf Schutzregeln speichern.

8. Optional kannst du die festlegen, dass die Umgehung konfigurierter Schutzregeln nicht zugelassen wird. Weitere Informationen findest du unter Administratoren erlauben, konfigurierte Schutzregeln zu umgehen.

   1. Deaktiviere Administratoren erlauben, konfigurierte Schutzregeln zu umgehen.
   2. Klicke auf Schutzregeln speichern.

9. Optional kannst du alle benutzerdefinierten Regeln für den Bereitstellungsschutz aktivieren, die mit GitHub Apps erstellt wurden. Weitere Informationen findest du unter Benutzerdefinierte Regeln für den Bereitstellungsschutz.

   1. Wähle die benutzerdefinierte Schutzregel aus, die du aktivieren möchtest.
   2. Klicke auf Schutzregeln speichern.

10. Geben Sie optional an, welche Branches in dieser Umgebung Bereitstellungen durchführen können. Weitere Informationen finden Sie unter „Bereitstellungsbranches“.

    1. Wähle die gewünschte Option im Dropdownmenü Bereitstellungsbranches aus.

    2. Wenn Sie Ausgewählte Branches ausgewählt haben, klicken Sie zum Hinzufügen einer neuen Regel auf Regel für Bereitstellungsbranch hinzufügen

    3. Geben Sie das Namensmuster für den Branch ein, den/das Sie zulassen möchten.

    4. Klicken Sie auf Regel hinzufügen.

11. Optional kannst du Umgebungsgeheimnisse hinzufügen. Diese Geheimnisse sind nur für Workflowaufträge verfügbar, die die Umgebung verwenden. Außerdem können Workflowaufträge mit Verwendung dieser Umgebung erst dann auf diese Geheimnisse zugreifen, wenn alle konfigurierten Regeln (z. B. erforderliche Reviewer) erfüllt sind. Weitere Informationen findest du unter Umgebungsgeheimnisse.

    1. Klicke unter Umgebungsgeheimnisse auf Geheimnis hinzufügen.
    2. Gib den Geheimnisnamen ein.
    3. Gib den Geheimniswert ein.
    4. Klicke auf Geheimnis hinzufügen.

12. Optional kannst du Umgebungsvariablen hinzufügen. Diese Variablen stehen nur für Workflowaufträge zur Verfügung, die die Umgebung verwenden, und sind nur über den vars-Kontext zugänglich. Weitere Informationen finden Sie unter Umgebungsvariablen.

    1. Klicke unter Umgebungsvariablen auf Variable hinzufügen.
    2. Gib den Namen der Variablen ein.
    3. Gib den Wert der Variablen ein.
    4. Klicke auf Variable hinzufügen.

Du kannst auch Umgebungen über die REST-API erstellen und konfigurieren. Weitere Informationen findest du unter REST-API-Endpunkte für Bereitstellungsumgebungen, REST-API-Endpunkte für GitHub-Actions-Geheimnisse, REST-API-Endpunkte für GitHub-Actions-Variablen und REST-API-Endpunkte für Richtlinien für Bereitstellungsbranches.

Wenn du einen Workflow ausführst, der auf eine nicht vorhandene Umgebung verweist, wird eine Umgebung mit dem referenzierten Namen erstellt. Wenn die Umgebung aus der Ausführung impliziter Seitenbuilds (z. B. aus einer Verzweigung oder einer Ordnerquelle) erstellt wird, wird die Quellverzweigung als Schutzregel zur Umgebung hinzugefügt. Andernfalls werden für die neu erstellte Umgebung keine Schutzregeln oder Geheimnisse konfiguriert. Jeder Benutzer, der Workflows im Repository bearbeiten kann, kann Umgebungen über eine Workflowdatei erstellen, aber nur Repositoryadministratoren können die Umgebung konfigurieren.

Löschen einer Umgebung

Um eine Umgebung in einem Repository eines persönlichen Kontos zu konfigurieren, musst du der Repositorybesitzer sein. Um eine Umgebung in einem Organisationsrepository zu konfigurieren, musst du admin-Zugriff haben.

Wenn du eine Umgebung löschst, werden alle Geheimnisse und Schutzregeln gelöscht, die dieser Umgebung zugeordnet sind. Alle Aufträge, die aufgrund von Schutzregeln aus der gelöschten Umgebung warten, schlagen automatisch fehl.

1. Navigieren Sie auf GitHub zur Hauptseite des Repositorys.

2. Wähle unter dem Namen deines Repositorys die Option Einstellungen aus. Wenn die Registerkarte „Einstellungen“ nicht angezeigt wird, wähle im Dropdownmenü die Option Einstellungen aus.

   

3. Klicke auf der linken Randleiste auf Umgebungen.

4. Klicke neben der Umgebung, die du löschen möchtest, auf .

5. Klicke auf Verstanden, diese Umgebung löschen.

Du kannst Umgebungen auch über die REST-API löschen. Weitere Informationen finden Sie unter REST-API-Endpunkte für Repositorys.

Beziehung zwischen Umgebungen und Bereitstellungen

Wenn ein Workflowauftrag, der auf eine Umgebung verweist, erstellt er ein Bereitstellungsobjekt mit der Eigenschaft environment, die auf den Namen Deiner Umgebung festgelegt ist. Im Verlauf des Workflows werden außerdem Bereitstellungsstatusobjekte erstellt, deren Eigenschaft environment auf den Namen Deiner Umgebung, deren Eigenschaft environment_url auf die URL der Umgebung (falls im Workflow angegeben) und deren Eigenschaft state auf den Status des Auftrags gesetzt ist.

Du kannst auf diese Objekte über die REST-API oder die GraphQL-API zugreifen. Du kannst diese Webhookereignisse auch abonnieren. Weitere Informationen findest du unter REST-API-Endpunkte für Repositorys, Objects (GraphQL-API) oder Webhook-Ereignisse und -Nutzlasten.

Nächste Schritte

GitHub Actions bietet verschiedene Funktionen zum Verwalten deiner Bereitstellungen. Weitere Informationen finden Sie unter Bereitstellen mit GitHub Actions.