Bereitstellungen und Umgebungen

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 Bereitstellungsschutzregeln verwenden, um eine manuelle Genehmigung zu erfordern, einen Auftrag zu verzögern oder die Umgebung auf bestimmte Branches einzuschränken. Du hast auch die Möglichkeit, benutzerdefinierte Schutzregeln zu erstellen und zu implementieren, die von GitHub Apps unterstützt werden. Auf diese Weise kannst du Drittanbietersysteme für die Steuerung von Bereitstellungen verwenden, die auf Umgebungen verweisen, die auf GitHub konfiguriert sind.

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.

Du hast 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. Die Wartezeit zählt nicht zur abrechenbaren Zeit.

Bereitstellungsbranches und -tags

Verwende Bereitstellungsbranches und -tags, um einzuschränken, welche Branches und Tags Bereitstellungen in der Umgebung durchführen können. Im Folgenden findest du 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 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 Branchschutzregeln 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 und Tags: Es können nur die Branches und Tags Bereitstellungen in der Umgebung durchführen, die den von dir angegebenen Namensmustern entsprechen.

  Wenn du releases/* als Bereitstellungsbranchregel oder Tagregel angibst, kann nur ein Branche oder Tag Bereitstellungen in der Umgebung durchführen, deren Name mit releases/ beginnt. (Platzhalterzeichen sind keine Entsprechung für /. Um Branches oder Tags abzugleichen, die mit release/ beginnen und einen zusätzlichen einzelnen Schrägstrich enthalten, verwende release/*/*.) Wenn du main als Branchregel hinzufügst, kann ein Branch namens main in der Umgebung bereitstellen. Weitere Informationen zu den Syntaxoptionen für Bereitstellungsbranches sind in der RubyFile.fnmatch-Dokumentation zu finden.

  Hinweis

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

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.