Skip to main content

Diese Version von GitHub Enterprise Server wurde eingestellt am 2023-09-12. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise Server. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Verwenden von Umgebungen für die Bereitstellung

Du kannst Umgebungen mit Schutzregeln und Geheimnissen konfigurieren. Ein Workflowauftrag, 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.

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.

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.

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

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

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.

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

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 deine GitHub Enterprise Server-Instanz 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. 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 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.
  9. 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.

Du kannst auch Umgebungen über die REST-API erstellen und konfigurieren. Weitere Informationen findest du unter Bereitstellungsumgebungen, GitHub Actions-Geheimnisse, 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 deine GitHub Enterprise Server-Instanz 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 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.