Verwenden Sie die GitHub-Bereitstellungs-Gate-Fähigkeit, um zu entscheiden, ob eine neue Bereitstellung fortgesetzt oder angehalten werden soll.
Vorbereitungen
GitHub-Bereitstellungs-Gates werden nur unterstützt, wenn Sie Ihre GitHub-Instanz mit OAuth 2.0-Anmeldeinformationen für GitHub-Apps verbunden haben und das JWT-Bearer-Token verwenden. Weitere Informationen finden Sie unter OAuth 2.0-Anmeldeinformationen für GitHub Apps – JWT.
Standardmäßig ist der Abschnitt „Regeln für den Bereitstellungsschutz“ für Umgebungen in allen Repositorys verfügbar, die in der installierten GitHub-App ausgewählt wurden.
Erforderliche Rolle: Berechtigung zum Erstellen von Umgebungen in GitHub
Prozedur
- Navigieren Sie aus einem Repository zu Einstellungen > Umgebungen, und klicken Sie auf Neue Umgebung, um eine Umgebung zu erstellen.

- Wählen Sie im Abschnitt „Regeln für Bereitstellungsschutz“ den Namen der installierten GitHub-App aus, und wählen Sie Schutzregeln speichern aus.

-
Fügen Sie die anwenderdefinierte Aktion „ServiceNow DevOps Change Automation“ auf Schrittebene (z. B. changeRequest-Auftrag in Workflow-/YAML-Datei) in einem Pipeline-Auftrag hinzu, um den Change für Bereitstellungs-Gates zu erstellen.
Der Parameter
deployment-gate muss im folgenden JSON-Format hinzugefügt werden.
'{"environment":"deployment_gate","jobName":"Deploy"}'
Hier ist der Schlüsselwert
environment die Umgebung, die mit Bereitstellungsschutzregeln erstellt wurde, und der Schlüsselwert
jobName ist der Bereitstellungsauftrag, der in der Workflow-/YAML-Datei mit Abhängigkeit vom Change-Anforderungsauftrag erstellt wurde, der mit der anwenderdefinierten Aktion ServiceNow DevOps Change Automation konfiguriert wurde.

Wenn der für das Bereitstellungstor spezifische Workflow bzw. die YAML-Datei in GitHub-Aktionen ausgeführt wird, werden Details wie Change-Nummer, Change-URL und Status angezeigt, sobald der Change Request in ServiceNow erstellt wurde. 
Details wie Change-Kommentare, „Genehmigt von“, „Genehmigt am“ und Status werden im GitHub-Tool protokolliert, nachdem die Workflow-Ausführung von ServiceNow fortgesetzt wurde, d. h. wenn die Change-Anforderung genehmigt wird und der Status der Change-Anforderung auf „Implementieren in ServiceNow“ aktualisiert wird. 