Ihren DevOps Change-Prozess beschleunigen
Aktivieren Sie die Change-Beschleunigungsfunktion von DevOps Change-Geschwindigkeit für die automatische Erstellung von Change-Anforderungen in Ihrer Pipeline, und verwenden Sie Flows und Richtlinien für Change-Genehmigungen, um die Genehmigung unter bestimmten Bedingungen zu automatisieren.
Sie können Details für aktive Change-Anforderungen anzeigen, indem Sie zu navigieren .
Change-Steuerungsverfahren
Wenn die Change-Steuerung für einen Job in Ihrer Entwicklungspipeline DevOps aktiviert ist, wird automatisch eine Change-Anforderung erstellt und auf den Status Bewerten gesetzt, um die Genehmigung für die Ausführung der aktuellen Phase oder des aktuellen Jobs anzufordern, sofern für die Change-Anforderung eine Zuweisungsgruppe hinzugefügt wird. Change-Anforderungen können automatisch genehmigt werden, indem Bedingungen in einer Change-Genehmigungsrichtlinie konfiguriert werden.
Pipeline-Schritte können so konfiguriert werden, dass Change-Belege aktiviert werden, die die Pipeline nicht anhalten. Change-Anforderungen, die mit aktivierten Change-Belegen erstellt wurden, enthalten alle Pipelinedaten, erfordern jedoch keine Genehmigung, um in der Pipeline fortzufahren, und die Change-Anforderung befindet sich im Status „Nachimplementierung“. Bei Change-Anforderungen, die ohne Aktivierung des Change-Empfangs erstellt wurden, wird die Pipeline angehalten, bis die Change-Anforderung genehmigt wird. Nach der Genehmigung wird die Pipeline fortgesetzt.
Wenn Sie den automatischen Übergang der Change-Anforderungsstatus auch dann stoppen möchten, wenn der Change-Beleg aktiviert ist, müssen Sie die Eigenschaft sn_devops.enable_change_receipt_state_transition deaktivieren. Weitere Informationen finden Sie unter DevOps Change-Geschwindigkeit -Eigenschaften.
Nach der Genehmigung (automatisch oder manuell) werden Change-Anforderungen in den Status Implementieren verschoben, und der Auftrag wird ausgeführt. Sobald der Auftrag ausgeführt wurde, wird die Change-Anforderung in den Status geschlossen verschoben, wobei der Abschlusscode bei erfolgreicher Auftragsausführung als erfolgreich oder bei einem Fehler in der Auftragsausführung als Nicht erfolgreich festgelegt wird. Informationen zum Anpassen der Status von Change-Anforderungen finden Sie unter Benutzerdefinierter Prozess für Change-Anforderungen.
Wenn eine Change-Anforderung nicht genehmigt und in den Status „Abgebrochen“ oder „Geschlossen“ verschoben wird, wird der zugehörige Jenkins- , GitHub- oder ADO-Auftrag als fehlgeschlagen markiert, und eine Konsolennachricht wird angezeigt:
Für Jenkins: [ServiceNow DevOps] Der Auftrag wurde nicht zur Ausführung genehmigt
Für GitHub: Fehler: **** Change wurde erstellt, aber der Change wurde entweder abgelehnt oder abgebrochen
Für ADO: „changeState":"Geschlossen“
Automatische Genehmigung von Change-Anforderungen mithilfe von Flows und Richtlinien
Sie können den Change-Genehmigungsprozess für alle Ihre DevOps-Change-Anforderungen automatisieren. DevOps Change-Geschwindigkeit verwendet Flows und DevOps-Daten (z. B. Arbeitselemente, Commits, Codeabdeckung, Codesicherheit, Risiko und Testergebnisse), um den Status einer Change-Anforderung zu aktualisieren und sie basierend auf Change-Genehmigungsrichtlinien automatisch zu genehmigen. Im Basissystem sind drei Flows verfügbar, die Sie klonen, anpassen und aktivieren können (in Flow Designer). Standardmäßig ist der manuelle Genehmigungs-Flow für DevOps-Change-Anforderungen aktiviert. DevOps-Flows gelten nur für automatisch erstellte Change-Anforderungen oder Change-Anforderungen, bei denen Change-Belege deaktiviert sind.
Flows
Ein Flow ist ein automatisierter Prozess, der aus einem Auslöser (der angibt, wann der Flow ausgeführt werden soll) und einer Sequenz von wiederverwendbaren Aktionen besteht (bei der die Aktionen eine Sequenz von Vorgängen für Ihre Daten ausführen). Flows werden in Flow Designer erstellt, einer Funktion der Now Platform, die die Prozessautomatisierung ermöglicht. Weitere Informationen finden Sie unter Flow Designer.
Sie können einen der im Basissystem verfügbaren DevOps-Flows als Vorlage verwenden. Klonen Sie den Flow, und passen Sie ihn an Ihre Geschäftsanforderungen an. Stellen Sie sicher, dass sich jeweils nur ein DevOps-Flow im aktiven Status befindet, um Konflikte und Fehler zu vermeiden. Ein DevOps-Flow gilt für Change-Anforderungen, für die die DevOps-Kategorie vorliegt oder für die die Eigenschaft „devops_change“ auf „true“ festgelegt ist. (Eine automatisch erstellte DevOps-Change-Anforderung legt die Kategorie standardmäßig auf DevOps fest.)
- Wenn die DevOps-Change-Anforderung genehmigt wird, aktualisiert der Flow den Status der Schrittausführung in „Genehmigt“ und der Status der Change-Anforderung wird in „Implementieren“ geändert. Danach wird die Pipeline fortgesetzt.
- Wenn die DevOps-Change-Anforderung abgelehnt wird, aktualisiert der Flow den Status der Schrittausführung auf „Abgelehnt“ und der Status der Change-Anforderung wird auf „Neu“ aktualisiert. Danach wird die Pipeline beendet.
- Wenn die DevOps-Change-Anforderung abgebrochen wird, aktualisiert der Flow den Status der Schrittausführung auf „Von Anwender abgebrochen“ und die Change-Anforderung wird auf „Abgebrochen“ aktualisiert. Danach wird die Pipeline abgebrochen.
Wenn eine Geschäftsregel oder Datenrichtlinie beim Aktualisieren einer Änderung im manuellen Genehmigungs-Flow für DevOps-Change-Anforderungen, im Genehmigungs-Flow für minimale Automatisierung für DevOps-Change-Anforderungen oder im Genehmigungs-Flow für erweiterte Automatisierung für DevOps-Change-Anforderungen einen Fehler verursacht, wird der entsprechende Fehler in den Arbeitsnotizen von angezeigt die Change-Anforderung geändert und in den Konsolenprotokollen des Pipeline-Tools protokolliert.
| DevOps-Flow | Standardverhalten |
|---|---|
| Manueller Genehmigungs-Flow für DevOps-Change-Anforderungen | Dieser Flow ist standardmäßig aktiviert. Bei diesem Flow müssen DevOps-Change-Anforderungen einen manuellen Genehmigungsprozess durchlaufen, bei dem der Flow wartet, bis die Change-Anforderung einen berechtigten Status erreicht (abgelehnt, implementiert oder bestimmter Implementierungsstatus). Bei Erreichen aktualisiert dieser Flow den Status der Schrittausführung basierend auf dem Status der Change-Anforderung. Wenn die Change-Anforderung typbasiert ist, wartet der Flow, bis der Change abgelehnt, implementiert oder abgebrochen wird. Wenn die Change-Anforderung modellbasiert ist, wartet der Flow, bis der Change abgelehnt oder abgebrochen wird oder einen der im Modell definierten Implementierungsstatus oder den in der DevOps-Eigenschaft angegebenen Implementierungsstatus erreicht. Dieser Flow wird für DevOps-Change-Anforderungen, deren Modell ein Basissystem-DevOps-Change-Modell (DevOps oder DevOps vereinfacht) ist, nicht ausgelöst, um Konflikte und Fehler zu vermeiden. Sie können diesen Flow klonen und anpassen, um Änderungen vorzunehmen. Stellen Sie sicher, dass die anderen DevOps-Flows deaktiviert sind. |
| DevOps – Change-Anforderung – Minimale Automatisierung – Genehmigungs-Flow | Dieser Flow sammelt DevOps-Daten und führt die Richtlinie für minimale Automatisierungsrichtlinie für DevOps-Change-Anforderungen aus, die bestimmt, ob der Change automatisch abgelehnt, automatisch genehmigt oder zur manuellen Genehmigung gesendet werden soll. Dieser Flow wird für DevOps-Change-Anforderungen ausgelöst, deren Typ oder Modell auf „Normal“ festgelegt ist. Aktivieren Sie diesen Flow, wenn Sie Genehmigungen von Change-Anforderungen automatisieren, aber mindestens starten möchten. Sie können diesen Flow klonen und anpassen, um Änderungen vorzunehmen. Stellen Sie sicher, dass die anderen DevOps-Flows deaktiviert sind. Sie können diesem Flow auch die Aktion DevOps – Minimale Automatisierungs-Richtlinienentscheidung aktualisieren hinzufügen, um die Richtlinienentscheidungen im Change-Kommentar der Schrittausführung und in den Arbeitsnotizen zur Change-Anforderung zu aktualisieren und die Gründe für die Entscheidung zu erfahren. Sie können diese Aktion in jedem Entscheidungsblock hinzufügen und die erforderliche Eingabe angeben. |
| DevOps – Change-Anforderung – Genehmigungs-Flow für erweiterte Automatisierung | Dieser Flow sammelt DevOps-Daten und führt die Richtlinie für erweiterte Automatisierungsrichtlinie für DevOps-Change-Anforderungen aus, die bestimmt, ob der Change automatisch abgelehnt, automatisch genehmigt oder zur manuellen Genehmigung gesendet werden soll. Dieser Flow wird für DevOps-Change-Anforderungen ausgelöst, deren Typ oder Modell auf „Normal“ festgelegt ist. Wenn die DevOps-Change-Anforderung genehmigt wird, aktualisiert der Flow die Change-Anforderung auf den geplanten Status, und das geplante Startdatum wird verwendet, um das Startdatum der Change-Anforderung festzulegen. Am Startdatum der Change-Anforderung aktualisiert der Flow den Status der Change-Anforderung in „Implementieren“. Danach wird die Pipeline fortgesetzt. Aktivieren Sie diesen Flow, wenn Sie die Genehmigung von Change-Anforderungen mit einer robusten Change-Richtlinie automatisieren möchten. Sie können diesen Flow klonen und anpassen, um Änderungen vorzunehmen. Stellen Sie sicher, dass die anderen DevOps-Flows deaktiviert sind. |
| DevOps-Demo-Flow für Change-Automatisierung | Wenn Demodaten installiert sind, ist der Flow „DevOps-Demo-Change-Automatisierung“ verfügbar, bei dem der normale Typ der Change-Anforderung oder die normale Modell-Change-Anforderung basierend auf den Entscheidungsrichtlinien automatisch genehmigt werden kann. Als Teil der Demodaten sind folgende Entscheidungsrichtlinien verfügbar:
|
Richtlinien zur effektiveren Verwendung von Flows, Subflows und Aktionen finden Sie unter General guidelines for Workflow Studio flows, subflows, and actions.
Richtlinien für Change-Genehmigungen
- Richtlinieneingabe: Variablenquellen, die innerhalb einer Bedingung ausgewertet werden.
- Entscheidungen: Bestimmt, ob die Change-Genehmigungsdefinition basierend auf Bedingungen angewendet werden muss.
- Genehmigungsdefinitionen: Definiert die Art der Genehmigung, die angewendet werden kann.
- Change-Richtlinie für DevOps-Modelle
- Minimale Automatisierungsrichtlinie für DevOps-Change-Anforderungen
- DevOps-Change-Anforderung – Richtlinie für erweiterte Automatisierung
Weitere Informationen zu Richtlinien für Change-Genehmigungen finden Sie unter Richtlinien für Change-Genehmigungen.
Die automatisierten Genehmigungs-Flows von DevOps verwenden Change-Genehmigungsrichtlinien und DevOps-Daten (z. B. Arbeitselemente, Commits, Abrufanforderungen, Testzusammenfassungen, Sicherheitszusammenfassungen und Qualitätszusammenfassungen), um den Status des Change-Datensatzes und den Status der Schrittausführung automatisch in „Genehmigt“, „Abgelehnt“ oder zu aktualisieren storniert. Sie können diese Richtlinien basierend auf Ihren Geschäftsanforderungen anzeigen und bearbeiten oder in der Entscheidungstabelle eigene erstellen. Sehen Sie sich die folgenden Entscheidungstabellen an.
Die Richtlinie für minimale Automatisierung für DevOps-Change-Anforderungen weist standardmäßig die folgenden Bedingungen und Kriterien auf:
Die Richtlinie für die erweiterte Automatisierungsrichtlinie für DevOps-Change-Anforderungen weist standardmäßig die folgenden Bedingungen und Kriterien auf:
- Automatische Genehmigung: Wenn die in der Richtlinie angegebenen Bedingungen erfüllt sind, wird die Change-Anforderung automatisch genehmigt.
- Automatische Ablehnung: Wenn eine oder mehrere der in der Richtlinie angegebenen Bedingungen nicht erfüllt sind, wird die Change-Anforderung automatisch abgelehnt.
- Manuelle Genehmigung: Wenn eine oder mehrere Bedingungen manuell von einem Benutzer oder einer Gruppe genehmigt werden müssen, wird dies in der Richtlinie angegeben. Benachrichtigungen werden von der Richtlinie an die relevanten Benutzer oder Gruppen gesendet, um die manuelle Genehmigung zu beschleunigen und die Change-Anforderung voranzutreiben.
Sie können Ihre Richtlinie für Change-Genehmigungen in der Aktion Change-Management-Workflow-Studio anwenden, um den Genehmigungsprozess für eine Change-Anforderung zu steuern. Weitere Informationen finden Sie unter Flow-Aktion „Apply Change Approval Policy“ (Richtlinie für Change-Genehmigung anwenden) verwenden.
Arbeitsnotizen für Change-Genehmigung
Wenn ein Change Request auf Grundlage einer Flow- und Change-Genehmigungsrichtlinie aktualisiert wird, werden die dem Change Request 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 übereinstimmenden Entscheidungen. %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 genehmigt (%s).
if (APPROVED.equals(state))
38 message = String.format(APPROVED_MSG, policyName, actionLabel);Subflow des Standard-Change-Handlers
- Angefordert von
- Begründung
- Implementierungsplan
- Rückfallplan
- Testplan
- Kurzbeschreibung
- Beschreibung
- Startdatum
- Enddatum
- Risikoauswirkungsanalyse
Der Subflow des Standard-Change-Handlers überschreibt die Feldwerte, die beim Erstellen des Change-Anforderungsdatensatzes mithilfe einer Vorlage ausgefüllt wurden.
Bei Bedarf können Sie anstelle dieses Flows einen anwenderdefinierten Subflow schreiben, indem Sie ändern [sn_devops.change_request_handler_subflow] DevOps user.
Anwenderdefinierte Change-Anforderungsvorlagen
Der Typ der Change-Anforderung entspricht der Change-Anforderungstabelle im globalen Bereich.
Zugehörige Listen für automatische Change-Anforderungen
- 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 Pipelineausführung, die einem Artefakt, einem Paket oder einer Aufgabenausführung vor der Change-Anforderung zugeordnet ist.
Weitere Informationen finden Sie unter Testergebnisse.
Anwenderdefinierter Change-Anforderungsprozess
Diese DevOps-Change-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-Anforderung-Flow anzupassen, müssen Sie zuerst einen erstellen . Beispiel: DevOps_Implement (Wert – 10).
Fügen Sie dann die Auswahlliste zu hinzu .
Nachdem Sie die Auswahlliste erstellt und der Skripteinbindung hinzugefügt haben, können Sie die DevOps-Change-Eigenschaften mit den neuen Auswahllistenwerten aktualisieren. Beispiel: DevOps change request implement state -10.
DevOps-Risikobedingung
Sie können die Risiko- und Auswirkungsberechnung DevOps basierend auf der Risikopunktzahl des Committers verwenden.
Diese Bedingung ist standardmäßig deaktiviert.
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, aber es sind keine Artefaktversionen registriert.
- Wenn die Change-Anforderung in der Paketerstellungsphase erstellt wird:
Es werden keine Testergebnisse angezeigt, da ein Paket noch nicht 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 Phase „Change-gesteuert“.
- Wenn die Change-Anforderung in der Paketerstellungsphase erstellt wird:
- Artefaktversionen sind registriert, aber es wird 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 Phase „Change-kontrolliert“.
- Wenn die Change-Anforderung in der Artefaktversionsphase erstellt wird:
- Sowohl die 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 darauffolgenden Phasen bis zur Phase „Von Change gesteuert“.
- 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 die Phasen danach, bis zur Phase „Change-gesteuert“.
- Wenn die Change-Anforderung Teil der Phase nach den Phasen „Artefaktversion“ und „Paketerstellung“ ist:
Ansicht Pipeline-Ausführungen
Sie können die Pipeline-Aktivität anzeigen, indem Sie zu navigieren .