Skip to main content

Verwalten von Umgebungen für die Bereitstellung

Sie können Umgebungen erstellen und diese Umgebungen mit Regeln für den Bereitstellungsschutz schützen. Ein Auftrag, der auf eine Umgebung verweist, muss alle Schutzregeln für diese Umgebung befolgen, ehe er ausgeführt wird oder auf die Geheimnisse der Umgebung zugreift.

Wer kann dieses Feature verwenden?

Repository owners

Environments, environment secrets, and deployment protection rules are available in public repositories for all current GitHub plans. They are not available on legacy plans, such as Bronze, Silver, or Gold. For access to environments, environment secrets, and deployment branches in private or internal repositories, you must use GitHub Pro, GitHub Team, or GitHub Enterprise.

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 finden Sie 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.

Note

In einem Repository kann eine beliebige Anzahl von auf GitHub Apps basierenden Regeln für den Bereitstellungsschutz installiert werden. Es dürfen jedoch maximal sechs Bereitstellungsschutzregeln gleichzeitig in jeder Umgebung aktiviert sein.

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.

Sie haben auch die Möglichkeit, Selbstüberprüfungen für Bereitstellungen in geschützten Umgebungen zu verhindern. Wenn Sie diese Einstellung aktivieren, können Benutzer, die eine Bereitstellung initiieren, den Bereitstellungsauftrag nicht genehmigen, auch wenn sie ein erforderlicher Prüfer sind. Dadurch wird sichergestellt, dass Bereitstellungen in geschützten Umgebungen immer von mehreren Personen überprüft werden.

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 und Tags

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

  • Keine Einschränkung: Keine Einschränkung der Bereitstellung durch Branches oder Tags in der Umgebung.

  • ** Nur 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“.

    Note

    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 und Tags: Nur Branches und Tags, die Ihrem vorgegebenen Namensmuster entsprechen, können in der Umgebung Bereitstellungen durchführen.

    Wenn Sie releases/* als Brereitstellungsbranch oder Tag regel angeben, kann nur ein Branch oder Tag, dessen Name mit releases/ beginnt, in der Umgebung Bereitstellungen durchführen. (Platzhalterzeichen sind keine Entsprechung für /. Damit Branches oder Tags, 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.

    Note

    Namensmuster müssen einzeln für Branches oder Tags konfiguriert werden.

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

Note

Benutzerdefinierte Regeln für den Bereitstellungsschutz befinden sich derzeit in der beta. Änderungen sind vorbehalten.

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.

Note

Workflows, die auf selbstgehosteten Runnern ausgeführt werden, werden nicht in einem isolierten Container ausgeführt. Dies gilt auch dann, wenn sie Umgebungen verwenden. Umgebungsgeheimnisse sollten mit der gleichen Sicherheitsstufe behandelt werden wie Repository- und Organisationsgeheimnisse. Weitere Informationen findest du unter Sicherheitshärtung für GitHub Actions.

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 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.

    Screenshot eines Repositoryheaders mit den Registerkarten. Die Registerkarte „Einstellungen“ ist dunkelorange umrandet.

  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. Um zu verhindern, dass Benutzer von Ihnen ausgelöste Workflowausführungen genehmigen, kann optional Selbstüberprüfung verhindern ausgewählt werden.
    4. 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 und Tags in dieser Umgebung Bereitstellungen durchführen können. Weitere Informationen finden Sie unter „Bereitstellungsbranches und Tags“.

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

    2. Wenn Sie Ausgewählte Branches und Tags ausgewählt haben, klicken Sie zum Hinzufügen einer neuen Regel auf Regel für Bereitstellungsbranch oder Tag hinzufügen 1. Klicke im Dropdownmenü "Ref type" auf Branch oder Tag, je nachdem, welche Regel du anwenden möchtest.

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

      Note

      Namensmuster müssen einzeln für Branches oder Tags konfiguriert werden.

    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 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 finden Sie 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.

    Screenshot eines Repositoryheaders mit den Registerkarten. Die Registerkarte „Einstellungen“ ist dunkelorange umrandet.

  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 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 findest du unter Bereitstellen mit GitHub Actions.