Verwenden 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.com 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 0 und 43.200 (30 Tage) sein.

Bereitstellungsbranches

Verwende Bereitstellungsbranches, um einzuschränken, welche Branches Bereitstellungen in der Umgebung durchführen können. Im Folgenden findest du 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 Schutzregeln können Bereitstellungen in der Umgebung 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“.

  Hinweis: Ausführungen von Bereitstellungsworkflows, die von Tags mit demselben Namen wie ein geschützter Branch oder Forks mit Branches, die dem Namen des geschützten Branches entsprechen, ausgelöst werden, können in der Umgebung nicht bereitgestellt werden.

• Ausgewählte Branches: Es können nur die Branches Bereitstellungen in der Umgebung durchführen, die den von dir angegebenen Namensmustern entsprechen.

  Wenn du zum Beispiel releases/* als Bereitstellungsbranchregel angibst, können nur Branches Bereitstellungen in der Umgebung durchführen, deren Name mit releases/ beginnt. (Platzhalterzeichen liefern keine Übereinstimmung mit /. Um Branches zu finden, die mit release/ beginnen und einen zusätzlichen einfachen Schrägstrich enthalten, verwendest du release/*/*). Wenn du main als Branchregel hinzufügst, kann auch ein Branch namens main Bereitstellungen in der Umgebung durchführen. Weitere Informationen zu den Syntaxoptionen für Bereitstellungsbranches findest du in der Ruby File.fnmatch-Dokumentation.

Administratoren erlauben, konfigurierte Schutzregeln zu umgehen

Standardmäßig können Administrator*innen die Schutzregeln umgehen und Bereitstellungen in bestimmten Umgebungen erzwingen. Weitere Informationen findest du 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. Du kannst z. B. Dienste wie Datadog, Honeycomb und ServiceNow verwenden, um automatisierte Genehmigungen für Bereitstellungen in GitHub.com 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 findest du unter 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. Navigiere auf GitHub.com 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*innen.
   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. Optional kannst du angeben, welche Branches Bereitstellungen in dieser Umgebung durchführen können. Weitere Informationen findest du unter Bereitstellungsbranches.
    1. Wähle die gewünschte Option im Dropdownmenü Bereitstellungsbranches aus.
    2. Wenn du Ausgewählte Branches ausgewählt hast, gib die Branchnamensmuster ein, die du zulassen möchtest.
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 findest du 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 Bereitstellungsumgebungen, GitHub Actions-Geheimnisse, GitHub Actions-Variablen, und 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. Für die neu erstellte Umgebung sind 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.

Verwenden einer Umgebung

Jeder Auftrag in einem Workflow kann auf eine einzelne Umgebung verweisen. Alle für die Umgebung konfigurierten Schutzregeln müssen eingehalten werden, bevor ein Auftrag, der auf die Umgebung verweist, an einen Runner gesendet wird. Der Auftrag kann erst dann auf die Geheimnisse der Umgebung zugreifen, wenn der Auftrag an einen Runner gesendet wird.

Wenn ein Workflow auf eine Umgebung verweist, wird die Umgebung in den Bereitstellungen des Repositorys angezeigt. Weitere Informationen zum Anzeigen aktueller und früherer Bereitstellungen findest du unter Anzeigen des Bereitstellungsverlaufs.

Du kannst eine Umgebung für jeden Auftrag in deinem Workflow angeben. Füge dazu einen jobs.<job_id>.environment-Schlüssel hinzu, gefolgt vom Namen der Umgebung.

Dieser Workflow verwendet beispielsweise eine Umgebung namens production.

name: Deployment

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: deploy
        # ...deployment-specific steps

Wenn der obige Workflow ausgeführt wird, unterliegt der deployment-Auftrag allen Regeln, die für die production-Umgebung konfiguriert sind. Wenn beispielsweise die Umgebung Prüfer erfordert, wird der Auftrag angehalten, bis einer der Prüfer den Auftrag genehmigt.

Du kannst auch eine URL für die Umgebung angeben. Die angegebene URL wird auf der Seite „Bereitstellungen“ für das Repository angezeigt (Zugriff erfolgt durch Klicken auf Umgebungen auf der Homepage deines Repositorys) und im Visualisierungsdiagramm für die Workflowausführung. Wenn ein Pull Request den Workflow ausgelöst hat, wird die URL auch als Schaltfläche Bereitstellung anzeigen in der Pull Request-Zeitachse angezeigt.

name: Deployment

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: 
      name: production
      url: https://github.com
    steps:
      - name: deploy
        # ...deployment-specific steps

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. Navigiere auf GitHub.com 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 findest du unter 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 Repositorys (REST-API), Objects (GraphQL-API) oder Webhook-Ereignisse und -Nutzlasten.

Nächste Schritte

GitHub Actions bietet verschiedene Funktionen zum Verwalten deiner Bereitstellungen. Weitere Informationen findest du unter Bereitstellen mit GitHub Actions.