Beschleunigen Sie Ihre DevOps Change-Prozess

  • Freigeben Version: Zurich
  • Aktualisiert 31. Juli 2025
  • 5 Minuten Lesedauer
  • Aktivieren Sie die Change-Beschleunigungsfunktion von DevOps Change-Geschwindigkeit Für die automatische Erstellung von Change-Anforderungen in Ihrer Pipeline und verwenden Sie Change-Genehmigungs-Flows und -Richtlinien, um die Genehmigung unter bestimmten Bedingungen zu automatisieren.

    Hinweis:
    ServiceNow Change-Management Muss für Change-Beschleunigung installiert sein.
    Aktivieren und richten Sie die Change-Steuerung ein, wenn Sie Ihre Pipeline in modellieren DevOps:

    Sie können Details für aktive Change-Anforderungen anzeigen, indem Sie zu navigieren DevOps > Orchestrieren > Pipeline-Change-Anforderungenan.

    Change-Steuerungsprozess

    Wenn Change-Steuerung für einen Auftrag in aktiviert ist DevOps Entwicklungs-Pipeline wird eine Change-Anforderung automatisch erstellt und auf den Status „Bewerten“ gesetzt, um die Genehmigung für die Ausführung der aktuellen Phase oder des aktuellen Auftrags anzufordern, wenn eine Zuweisungsgruppe für die Change-Anforderung hinzugefügt wird. Change-Anforderungen können automatisch genehmigt werden, indem Bedingungen in einer Change-Genehmigungsrichtlinie konfiguriert werden.

    Wenn eine Change-Anforderung nicht genehmigt und in den Status „Abgebrochen“ oder „Geschlossen“ verschoben wird, wird die zugeordnete Jenkins, GitHub- oder ADO-Auftrag ist als fehlgeschlagen markiert, und eine Konsolennachricht wird angezeigt:

    Für Jenkins: [ServiceNow DevOps] Auftrag wurde nicht zur Ausführung genehmigt

    Für GitHub: Fehler: **** Change wurde erstellt, der Change wurde jedoch entweder abgelehnt oder abgebrochen

    Für ADO: „ChangeState“:„Geschlossen“

    Arbeitsnotizen zur Change-Genehmigung

    Wenn eine Change-Anforderung basierend auf einem Flow und einer Change-Genehmigungsrichtlinie aktualisiert wird, werden die der Change-Anforderung zugeordneten Arbeitsnotizen auf eine der folgenden hartcodierten Nachrichten aktualisiert:

    • Richtlinie für Change-Genehmigung nicht gefunden. Change-Anforderung wurde abgelehnt (%s).
    • %S ist inaktiv. Change-Anforderung wurde abgelehnt (%s).
    • Keine Entscheidungen stimmen überein. %S wurde übersprungen (%s).
    • Aus übereinstimmenden Entscheidungen wurden keine Genehmigungen generiert. %S wurde übersprungen (%s).
    • Change-Anforderung wurde von %s (%s) abgelehnt.
    • Change-Anforderung wurde von %s (%s) genehmigt.
    Die Arbeitsnotizen werden basierend auf einer Logik aktualisiert, die die Kombination aus einer der hartcodierten Nachrichten + dem Richtliniennamen + der Aktionsbezeichnung verwendet, die im Flow verwendet wird, der der Change-Anforderung zugeordnet ist. In dieser Kombination können Sie nur den Wert des Richtliniennamens und der Aktionsbezeichnung ändern, aber nicht die hartcodierte Nachricht. Beispiel:
    if (APPROVED.equals(state))
    38 message = String.format(APPROVED_MSG, policyName, actionLabel);

    Standard-Change-Handler-Subflow

    Verwenden Sie den Subflow Standard-Change-Handler, um diese Change-Anforderungsfelder mit Standardwerten auszufüllen.
    • Angefordert von
    • Begründung
    • Implementierungsplan
    • Rückfallplan
    • Testplan
    • Kurzbeschreibung
    • Beschreibung
    • Startdatum
    • Enddatum
    • Risikoauswirkungsanalyse

    Der Subflow „Standard-Change-Handler“ überschreibt die Feldwerte, die beim Erstellen des Change-Anforderungsdatensatzes mithilfe einer Vorlage ausgefüllt wurden.

    Bei Bedarf können Sie einen anwenderdefinierten Subflow anstelle dieses Flows schreiben, indem Sie ändern [sn_devops.change_request_handler_subflow] DevOps useran.

    Anwenderdefinierte Change-Anforderungsvorlagen

    Wenn Sie die Change-Steuerung in aktivieren ServiceNow DevOps Schritt , Sie können eine anwenderdefinierte Vorlage auswählen, um Felder beim Erstellen der Change-Anforderung automatisch auszufüllen. Die Change-Anforderung Kategorie Feld wird automatisch auf festgelegt DevOps.
    Hinweis:
    Konfigurieren Sie nicht Kategorie Und ChangetType Felder aus der anwenderdefinierten Vorlage.

    Der Typ der Change-Anforderung entspricht der Change-Anforderungstabelle im globalen Bereich.

    Zugehörige Listen für automatische Change-Anforderungen

    Für eine Change-Anforderung, die von automatisch erstellt wurde DevOps, Kategorie Feld wird automatisch auf DevOps festgelegt, und diese zugehörigen Listen werden hinzugefügt:
    Commits
    Commits, die der Change-Anforderung zugeordnet sind.
    Arbeitselemente
    Arbeitselemente, die der Change-Anforderung zugeordnet sind.
    Artefaktversionen

    Liste der Artefaktversionen, die dem Paket zugeordnet sind, das mit der Pipeline-Ausführung für Pakete verknüpft ist, die vor der Genehmigung der Change-Anforderung erstellt wurden.

    Wenn kein Paket mit der Pipeline-Ausführung verknüpft ist, ist die Liste leer.

    Testzusammenfassungen (ersetzt zugehörige Liste „Testergebnisse“)

    Liste der Testzusammenfassungen für eine Pipeline-Ausführung, die einem Artefakt, einem Paket oder einer Aufgabenausführung vor der Change-Anforderung zugeordnet ist.

    Siehe Testergebnisse Für weitere Details.

    Softwarequalitätszusammenfassung
    Liste der Softwarequalitätszusammenfassungen für eine Pipeline-Ausführung, die einem Artefakt, einem Paket oder einer Aufgabenausführung vor der Change-Anforderung zugeordnet ist.
    Sicherheitszusammenfassungen
    Liste der Sicherheitszusammenfassungen für eine Pipeline-Ausführung, die einem Artefakt, einem Paket oder einer Aufgabenausführung vor der Change-Anforderung zugeordnet ist.
    Hinweis:
    Die Ergebnisse der Sicherheitsscans im Change-Datensatz, der einer Pipeline-Ausführung mit einem verknüpften Paket zugeordnet ist, werden auch auf der Registerkarte Sicherheitszusammenfassungen angezeigt.

    Zugehörige DevOps-Change-Listen

    Hinweis:
    Implementierungsdetails aus dem Orchestration-Tool werden automatisch zu hinzugefügt Arbeitsnotizen Feld im Change-Anforderungsformular. Die den Arbeitsnotizen hinzugefügten Details sind auf 5 KB des Aufgabenausführungsprotokolls für den Schritt beschränkt.

    Anwenderdefinierter Change-Anforderungsprozess

    Diese DevOps ändert Eigenschaften Sind verfügbar, um Ihren Change-Anforderungs-Flow anzupassen.

    • Implementierungsstatus der DevOps-Change-Anforderung
    • Status der DevOps-Change-Anforderung nach der Implementierung
    • Abbruchstatus der DevOps-Change-Anforderung
    • Genehmigungstext der DevOps-Change-Anforderung

    Um Ihren Change-Anforderungs-Flow anzupassen, müssen Sie zuerst einen erstellen Systemdefinition > Auswahllistean. Beispiel: DevOps_Implementation (Wert – 10) .

    Fügen Sie dann die Auswahlliste zu hinzu Systemdefinition > Skripteinbindung > ChangeRequestStateHandlerSNCan.

    Sobald Sie die Auswahlliste erstellt und der Skripteinbindung hinzugefügt haben, können Sie aktualisieren DevOps ändert Eigenschaften Mit den neuen Auswahllistenwerten. Beispiel: DevOps change request implement state -10 .

    DevOps-Risikobedingung

    Sie können verwenden DevOps Risiko- und Auswirkungsberechnung basierend auf der Risikopunktzahl des Committers.

    Diese Bedingung ist standardmäßig inaktiv.

    Zugehörige Liste „Testergebnisse“

    Listet die Tests auf, die in einer Pipeline ausgeführt wurden, nachdem ein Paket erstellt wurde. Wenn kein Paket erstellt wurde, enthält die Liste die Tests, die nach der Erstellung einer Artefaktversion ausgeführt wurden.

    Szenarien:

    In der Pipeline wird ein Paket erstellt, es sind jedoch keine Artefaktversionen registriert.
    • Wenn die Change-Anforderung in der Phase der Paketerstellung erstellt wird:

      Es werden keine Testergebnisse angezeigt, da noch kein Paket mit der Pipeline-Ausführung verknüpft ist.

    • Wenn die Change-Anforderung in einer Phase nach der Paketerstellungsphase erstellt wird:

      Build-Testzusammenfassungen umfassen diejenigen, die Phasen nach der Paketerstellungsphase zugeordnet sind, bis zur Change-gesteuerten Phase.

    Artefaktversionen sind registriert, es wird jedoch kein Paket erstellt.
    • Wenn die Change-Anforderung in der Artefaktversionsphase erstellt wird:

      Es werden keine Testergebnisse angezeigt, da bis zum Abschluss der Aufgabenausführung keine Tests zugeordnet sind.

    • Wenn die Change-Anforderung in einer Phase nach der Artefaktversionsphase erstellt wird:

      Build-Testzusammenfassungen umfassen diejenigen in der Artefaktversionsphase sowie die Phasen danach bis zur Change-gesteuerten Phase.

    Sowohl Artefaktversionen als auch das Paket werden in der Pipeline erstellt.
    • Wenn die Change-Anforderung Teil der Phase nach den Phasen Artefaktversion und Paketerstellung ist:

      Build-Testzusammenfassungen umfassen diejenigen, die der Paketerstellungsphase zugeordnet sind, sowie die Phasen danach bis zur Change-gesteuerten Phase.

    • Wenn die Change-Anforderung Teil der Paketerstellungsphase ist und Artefaktversionen als Teil einer früheren Phase erstellt werden;
      • Oder die Change-Anforderung wird in einer Phase (nicht Paketerstellung) nach der Artefaktversionsphase, aber vor der Paketerstellungsphase erstellt.
      • Oder die Change-Anforderung ist Teil der Paketerstellungsphase, und Artefaktversionen werden als Teil einer früheren Phase erstellt:

      Build-Testzusammenfassungen umfassen diejenigen, die der Artefaktversionsphase zugeordnet sind, sowie Phasen danach bis zur Change-gesteuerten Phase.

    Ansicht „Pipeline-Ausführungen“

    Sie können die Pipeline-Aktivität anzeigen, indem Sie zu navigieren DevOps > Orchestrieren > Pipeline-Ausführungenan.

    DevOps-Pipeline-Ausführung