DevOps Change-Modelle
DevOps Change-Geschwindigkeit Mit können Sie zweckmäßige Change-Modelle verwenden, die eine größere Flexibilität bei der Definition von Change-Modellen oder Prozessen ermöglichen, um die modernen Entwicklungspraktiken widerzuspiegeln.
Übersicht über das DevOps-Change-Modell
Wichtig:
Verwenden Sie für DevOps-Change-Anforderungen die Funktion „Change-Management – Change-Modelle“, die mehr Flexibilität bietet, um den Change-Prozess-Flow auf eine Weise zu aktivieren, die für bestimmte Anwendungsfälle optimiert ist. Weitere Informationen finden Sie unter Change-Modelle. Das Legacy Change-Management - Statusmodell wird ebenfalls unterstützt. Weitere Informationen finden Sie unter Status-Modell und Übergänge.
Wichtig:
Die vereinfachten Change-Modelle von DevOps und DevOps werden für Argo CD- und Split-Tool-Change-Anforderungen nicht unterstützt.
Verwenden Sie zweckmäßige Change-Modelle mit einer Reihe von prägnanten Flows und Flow-Aktionen, die in Flow Designer für bestimmte Anwendungsfälle erstellt wurden. Anstatt die veralteten ITIL-basierten Change-Prozesse zu verwenden, die in Change-Workflows (Normal, Standard und Notfall) vordefiniert sind, können Sie selektiv zu einer Vielzahl von Modellen übergehen, die für bestimmte Anwendungsfälle optimiert sind. Change-Modelle können mit Status und Regeln erstellt werden, die die Übergänge zwischen den Status bestimmen. Informationen zu Change-Modellen finden Sie unter Change-Modelle.
Sie können jedes der Change-Modelle des Basissystems verwenden, einschließlich des vereinfachten DevOps- oder DevOps-Change-Modells. Um eine Change-Anforderung basierend auf Modellen zu erstellen, können Sie entweder das Feld Modell im Schrittformular in ServiceNow konfigurieren oder die sys_id oder den Namen des Modells im Change-Schritt aus Ihrer Orchestration-Pipeline übergeben.
Basissystem-DevOps-Change-Modelle
Zwei Change-Modelle mit den Namen DevOps und DevOps vereinfacht sind im Basissystem enthalten und standardmäßig aktiv, damit Sie eine modellbasierte Change-Anforderung erstellen können.
- Typ-Kompatibilitätskennzeichnung
-
Die Eigenschaft „Typkompatibilität com.snc.change_management.change_model.type_compatibility “ wird verwendet, um zu bestimmen, welche Arten von Change-Anforderungen (typ- oder modellbasiert) erstellt werden. Navigieren Sie zu Systemeigenschaften > Alle Eigenschaften, um den Wert für diese Eigenschaft festzulegen. Der Standardwert dieser Eigenschaft ist False. Diese Eigenschaft ermöglicht die Kompatibilität von Change-Typen für Change-Modelle. Bei Festlegung auf „true“ kann die Change-Anforderung entweder als typbasierter Workflow oder als Change-Modell erstellt werden. Bei Festlegung auf „falsch“ wird die Change-Anforderung nur mit dem Change-Modell erstellt.
Die Change-Anforderung wird basierend auf der Konfigurationskombination erstellt, die in den folgenden Tabellen definiert ist, wenn die Eigenschaft auf „true“ oder „false“ festgelegt ist.
Tabelle : 1. Wenn die Typkompatibilitätseigenschaft auf true festgelegt ist Change-Attribut, das im Pipeline-Schritt in ServiceNow konfiguriert ist In der Pipeline übergebenes Change-Attribut Change-Attribut, das bei der Change-Anforderungs-Erstellung berücksichtigt wird Change-Modell:<any selected change model> Weder das Modell noch der Change-Typ werden übergeben. Modellbasierte Change-Anforderung wird erstellt Change-Modell:<any selected change model> Typ wird übergeben. Beispiel: Normal { "attributes": { "type": "normal" } }Typbasierte Change-Anforderung wird erstellt Change-Modell:<any selected change model> Beispiel: Modell 1. Anderes Modell wird übergeben. Beispiel: Modell 2.{ "attributes": { "chg_model": { "name": "Model 2" } } }Change wird basierend auf Modell 2 erstellt Change-Modell: Nicht angegeben
Change-Typ:<any selected change type>
Weder das Modell noch der Change-Typ werden übergeben Typbasierte Change-Anforderung wird erstellt Change-Typ:<any selected change type> Modell wurde übergeben. { "attributes": { "chg_model": { "name": "DevOps" } } }Modellbasierte Change-Anforderung wird erstellt Change-Typ:<any selected change type> . Beispiel: Normal Ein anderer Typ wird übergeben. Beispiel: Notfall.{ "attributes": { "type": "emergency" } }Change-Anforderung wird basierend auf dem Notfalltyp erstellt. Tabelle : 2. Wenn die Typkompatibilitätseigenschaft auf False festgelegt ist Change-Attribut, das im Pipeline-Schritt in ServiceNow konfiguriert ist In der Pipeline übergebenes Change-Attribut Change-Attribut, das bei der Change-Anforderungs-Erstellung berücksichtigt wird Change-Modell:<any selected change model> Weder das Modell noch der Change-Typ werden übergeben Modellbasierte Change-Anforderung wird erstellt Change-Modell:<any selected change model> Typ wird übergeben. Beispiel: Normal { "attributes": { "type": "normal" } }Fehler Die Change-Anforderung kann nicht erstellt werden, da die Kennzeichnung für die Typkompatibilität deaktiviert ist. Aktivieren Sie die Typkompatibilitätskennzeichnung in den Systemeigenschaften, oder konfigurieren Sie das Change-Modell im Schrittdatensatz in ServiceNow, oder geben Sie die entsprechende Sys-ID oder den Namen des Change-Modells in die Pipeline ein.
Informationen zur Behebung dieses Fehlers finden Sie unter Häufige Fehler in DevOps Change-Geschwindigkeit.
Change-Modell:<any selected change model> Beispiel: Modell 1. Anderes Modell wird übergeben. Beispiel: Modell 2.{ "attributes": { "chg_model": { "name": "Model 2" } } }Change wird basierend auf Modell 2 erstellt Change-Modell: Nicht angegeben
Change-Typ:<any selected change type>
Weder das Modell noch der Change-Typ werden übergeben. Fehler Die Change-Anforderung kann nicht erstellt werden, da entweder der Change-Typ oder das Change-Modell nicht für die Pipeline konfiguriert ist.
Informationen zur Behebung dieses Fehlers finden Sie unter Häufige Fehler in DevOps Change-Geschwindigkeit.
Change-Typ:<any selected change type> Modell wurde übergeben. { "attributes": { "chg_model": { "name": "DevOps" } } }Modellbasierte Change-Anforderung wird erstellt Change-Typ:<any selected change type> . Beispiel: Normal Ein anderer Typ wird übergeben. Beispiel: Notfall.{ "attributes": { "type": "emergency" } }Fehler Die Change-Anforderung kann nicht erstellt werden, da die Kennzeichnung für die Typkompatibilität deaktiviert ist. Aktivieren Sie die Typkompatibilitätskennzeichnung in den Systemeigenschaften, oder konfigurieren Sie das Change-Modell im Schrittdatensatz in ServiceNow, oder geben Sie die entsprechende Sys-ID oder den Namen des Change-Modells in die Pipeline ein.
Informationen zur Behebung dieses Fehlers finden Sie unter Häufige Fehler in DevOps Change-Geschwindigkeit.
- Konfiguration von DevOps-Modellen
-
In den Change-Modellen des Basissystems ist für das Feld Implementierungsstatus der Wert Implementieren festgelegt, und für das Feld Datensatzvoreinstellung ist standardmäßig Typ=Normal ausgewählt. Die für das DevOps-Change-Modell verfügbaren Modellstatus sind Neu, Bewerten, Autorisieren, Geplant, Implementieren, Überprüfen, Geschlossen und Abgebrochen. Die für das vereinfachtes Change-Modell von DevOps verfügbaren Modellstatus sind Neu, Autorisieren, Geplant, Implementieren, Überprüfen, Geschlossen und Abgebrochen. Je nach Anforderungen können Sie die Change-Modelle ändern und die Status und Übergänge für Ihren spezifischen Anwendungsfall konfigurieren.
Abbildung : 1. DevOps Change-Modell Abbildung : 2. DevOps – Vereinfachtes Change-Modell Wenn Sie ein eigenes Modell erstellen möchten, anstatt die DevOps-Modelle des Basissystems zu verwenden, lesen Sie die Anweisungen im Abschnitt Change-Modell erstellen.
Sie können Datensatzvoreinstellungen verwenden, um Change-Details für Ihr Change-Modell zu konfigurieren. Wenn ein Change erstellt wird, werden diese Werte automatisch auf den Change festgelegt. Sie können eine Datensatzvoreinstellung für jedes Change-Feld festlegen, das in der Change-Anforderung vorhanden ist.
Die folgende Logik wird für die Vorabarchivierung der Change-Details beim Erstellen einer Change-Anforderung berücksichtigt.- Wenn Sie Change-Details in der Datensatzvoreinstellung konfiguriert haben, können Sie diesen Wert nicht überschreiben, indem Sie Change-Details aus der Pipeline übergeben.
- Wenn in der Datensatzvoreinstellung keine Change-Details konfiguriert sind, werden die von der Pipeline übergebenen Werte für die Vorabspeicherung der Details im Change Request berücksichtigt.
- Wenn Change-Details weder in der Datensatzvoreinstellung konfiguriert noch von der Pipeline übergeben werden, werden die im Schrittformular in ServiceNow konfigurierten Werte berücksichtigt.
In der Datensatzvoreinstellung in ServiceNow konfigurierte Change-Details Change-Details, die im Schrittformular in ServiceNow konfiguriert sind In der Pipeline übergebene Change-Details Change-Details, die beim Erstellen des Change vorab ausgefüllt werden Zuweisungsgruppe: DevOps-Bericht Zuweisungsgruppe: Nicht angegeben Zuweisungsgruppe: Nicht angegeben Die Zuweisungsgruppe wird aus der Datensatzvoreinstellung im Change Request vorab ausgefüllt Zuweisungsgruppe: Nicht konfiguriert Zuweisungsgruppe: Nicht angegeben Zuweisungsgruppe: DevOps-Bericht Die Zuweisungsgruppe wird im Change Request aus der Pipeline vorab ausgefüllt Zuweisungsgruppe: Nicht konfiguriert Zuweisungsgruppe: DevOps-Bericht Zuweisungsgruppe: Nicht angegeben Die Zuweisungsgruppe wird im Formular „Schritt“ im Change Request vorab ausgefüllt
DevOps Change-Modell
Das DevOps-Change-Modell enthält im Basissystem Flows für Statusübergänge und Change-Genehmigungen. Jeder Status im DevOps-Modell hat eigene Flows, und jeder Flow wird ausgelöst, wenn die erforderlichen Bedingungen erfüllt sind. Die Change-Genehmigung (automatisch oder manuell) basiert auf der Change-Richtlinie des DevOps-Modells. Standardmäßig ist für die DevOps-Modell-Change-Richtlinie des Basissystems nur die manuelle Genehmigungsentscheidung aktiviert. Wenn Sie für mehr Genehmigungsautomatisierung bereit sind, können Sie die Richtlinie ändern. Die folgenden Flows erläutern das Verhalten beim Statusübergang und bei der Change-Genehmigung.- Change – DevOps – Neu: Wenn die Change-Anforderung im Status „Neu“ erstellt wird, wird dieser Flow ausgelöst. Wenn eine Zuweisungsgruppe vorhanden ist, aktualisiert dieser Flow den Change-Status in Bewerten.
- Change – DevOps – Bewerten: Wenn sich die Change-Anforderung im Status „Bewerten“ befindet, wird dieser Flow ausgelöst. Dieser Flow enthält zwei wichtige Aktionen: „DevOps – Change-Richtliniendaten sammeln“ und „Change-Genehmigungsrichtlinie anwenden“, die verwendet werden, um die der Change-Anforderung zugeordneten DevOps-Daten abzurufen und zu überprüfen, ob die Change-Anforderung automatisch genehmigt, automatisch abgelehnt oder gesendet werden muss Manuelle Genehmigung Die Change-Genehmigung (automatisch oder manuell) erfolgt als Teil dieses Flows in der Aktion Change-Genehmigungsrichtlinie anwenden basierend auf der DevOps-Modell-Change-Richtlinie. Wenn der Change genehmigt wird (automatisch oder manuell), wechselt er in den Status Autorisieren. Wenn der Change abgelehnt wird, wird eine E-Mail-Benachrichtigung an den Benutzer gesendet, der den Change angefordert hat, und der Change wird in den Status Neu zurückversetzt.
- Change – DevOps – Autorisieren: Wenn sich die Change-Anforderung im Status „Autorisieren“ befindet, wird dieser Flow ausgelöst. Im Basissystem sehen Sie, dass es zwei wichtige Aktionen gibt – „DevOps – Change-Richtliniendaten sammeln“ und „Change-Genehmigungsrichtlinie anwenden“, die verwendet werden, um die mit der Change-Anforderung verknüpften DevOps-Daten abzurufen und zu überprüfen, ob die Change-Anforderung automatisch genehmigt werden muss. automatisch abgelehnt oder zur manuellen Genehmigung gesendet. Die Bedingungen in der DevOps-Modell-Change-Richtlinie in der Aktion „Change-Genehmigungsrichtlinie anwenden“ werden nicht erfüllt. Daher wird die Change-Genehmigung (automatisch oder manuell) in diesem Flow übersprungen. Dieser Flow verschiebt nur den Status der Change-Anforderung in „Geplant“, wodurch der Flow „Change – DevOps – Zeitplan“ ausgelöst wird. Hinweis:Wenn Ihr Change-Prozess eine weitere Genehmigung erfordert, können Sie auf diesen Flow verweisen und die Change-Richtlinie für DevOps-Modelle an Ihre Anforderungen anpassen.
- Change – DevOps – Zeitplan: Wenn sich die Change-Anforderung im Status „Geplant“ befindet, wird dieser Flow ausgelöst. Wenn das geplante Startdatum erreicht ist, wird der Change in den Status Implementieren verschoben.
- Change - DevOps - Implementieren: Wenn sich die Change-Anforderung im Status Implementieren befindet, wird dieser Flow ausgelöst.
Die DevOps-Modell-Change-Richtlinie enthält die folgenden Richtlinieneingaben:
- is_change_with_partial_data
- regression_tests_failed
- code_security
- code_coverage
- total_num_of_commits
- tests_passing_percent
- load_tests_failed
- num_of_open_incidents
- num_of_outages_in_last_7_days
- num_of_current_outages
- integration_tests_failed
- commits_without_work_item
- change_request
- Risiko
Die drei Ergebnisse für die DevOps-Modell-Change-Richtlinie (abhängig von den von Ihnen angegebenen Bedingungen) sind:
- 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.Hinweis:Standardmäßig ist für die DevOps-Modell-Change-Richtlinie des Basissystems nur die manuelle Genehmigungsentscheidung aktiviert.
Wichtig:
Wenn Sie das DevOps-Basissystemmodell unverändert verwenden, wird die Change-Genehmigung standardmäßig automatisiert. Wenn Sie keine automatisierte Change-Genehmigung wünschen, können Sie die Change-Richtlinie des DevOps-Modells so ändern, wie sie Ihrem aktuellen Change-Prozess entspricht.
Vereinfachtes DevOps-Modell
Das vereinfachte Change-Modell von DevOps enthält Flows im Basissystem für Statusübergänge und Change-Genehmigungen. Jeder Status im vereinfachten DevOps-Modell hat eigene Flows, und jeder Flow wird ausgelöst, wenn die erforderlichen Bedingungen erfüllt sind. Die Change-Genehmigung (automatisch oder manuell) basiert auf der Change-Richtlinie für vereinfachte Modelle von DevOps. In den folgenden Flows wird das Statusübergangs- und Change-Genehmigungsverhalten erläutert.
- Change – DevOps vereinfacht – Neu: Wenn die Change-Anforderung im Status „Neu“ erstellt wird, wird dieser Flow ausgelöst. Wenn eine Zuweisungsgruppe vorhanden ist, aktualisiert dieser Flow den Change-Status in Bewerten.
- Change – DevOps vereinfacht – Autorisieren: Wenn sich die Change-Anforderung im Status „Autorisieren“ befindet, wird dieser Flow ausgelöst. Dieser Flow enthält zwei wichtige Aktionen: „DevOps – Change-Richtliniendaten sammeln“ und „Change-Genehmigungsrichtlinie anwenden“, die verwendet werden, um die der Change-Anforderung zugeordneten DevOps-Daten abzurufen und zu überprüfen, ob die Change-Anforderung automatisch genehmigt, automatisch abgelehnt oder gesendet werden muss Manuelle Genehmigung Die Change-Genehmigung (automatisch oder manuell) erfolgt als Teil dieses Flows in der Aktion „Richtlinie für Change-Genehmigung anwenden“ basierend auf der Change-Richtlinie für vereinfachtes DevOps-Modell. Wenn der Change genehmigt wird (automatisch oder manuell), wechselt er in den Status Zeitplan. Wenn der Change abgelehnt wird, wird eine E-Mail-Benachrichtigung an den Benutzer gesendet, der den Change angefordert hat, und der Change wird in den Status Neu zurückversetzt. Hinweis:Wenn Ihr Change-Prozess eine weitere Genehmigung erfordert, können Sie auf diesen Flow verweisen und die Change-Richtlinie für vereinfachte DevOps-Modelle an Ihre Anforderungen anpassen.
- Change – DevOps vereinfacht – Zeitplan: Wenn sich die Change-Anforderung im Status „Geplant“ befindet, wird dieser Flow ausgelöst. Wenn das geplante Startdatum erreicht ist, wird der Change in den Status Implementieren verschoben.
- Change – DevOps vereinfacht – Implementieren: Wenn sich die Change-Anforderung im Status Implementieren befindet, wird dieser Flow ausgelöst.
Die Change-Richtlinie für das vereinfachte DevOps-Modell enthält die folgenden Richtlinieneingaben:
- is_change_with_partial_data
- regression_tests_failed
- code_security
- code_coverage
- total_num_of_commits
- tests_passing_percent
- load_tests_failed
- num_of_open_incidents
- num_of_outages_in_last_7_days
- num_of_current_outages
- integration_tests_failed
- commits_without_work_item
- change_request
- Risiko
Die drei Ergebnisse für die Change-Richtlinie für das vereinfachte DevOps-Modell (abhängig von den von Ihnen angegebenen Bedingungen) sind:
- 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.Hinweis:Standardmäßig ist für die Change-Richtlinie für das vereinfachte DevOps-Modell des Basissystems nur die manuelle Genehmigungsentscheidung aktiviert.
Rückruf, um die Pipeline fortzusetzen
In DevOps Change-Geschwindigkeit werden die folgenden Überlegungen zum Senden einer Rückrufanforderung berücksichtigt.
- Die Implementierungsstatus werden verwendet, um einen Rückruf an das Orchestration-Tool des Drittanbieters zu senden. Wenn nur ein Implementierungsstatus im Change-Modell vorhanden ist, wird ein absoluter Vergleich durchgeführt. Wenn der von einem Change-Modell erstellte Change den festgelegten Implementierungsstatus erreicht, wird ein Rückruf an das Orchestration-Tool der Drittpartei gesendet.Hinweis:In Change-Modellen kann das Feld Implementierungsstatus einen oder mehrere Status haben. Sie können die Implementierungsstatus für jedes Change-Modell definieren. Weitere Informationen finden Sie unter Status-Modell und Übergänge.
- Wenn im Change-Modell mehrere Implementierungsstatus vorhanden sind, wird ein Rückruf an das Orchestration-Tool der Drittpartei in dem Status gesendet, in dem der Implementierungsstatus zuerst erreicht wird.
- Wenn für das Change-Modell kein Implementierungsstatus festgelegt ist, werden die Modellstatus auf den Status Implementieren überprüft. Wenn der Status „Implementieren“ vorhanden ist, wird dies für den Rückruf an das Orchestration-Tool der Drittpartei berücksichtigt. Wenn auch in den Modellstatus kein Implementierungsstatus vorhanden ist, wird der Wert in der Eigenschaft sn_devops.change_request.implement_state berücksichtigt. Der Wert der Systemeigenschaft ist standardmäßig -1 und entspricht dem Implementierungsstatus.
Hinweis:
Der Flow Change – DevOps – Update-Ausführungsstatus wird verwendet, um einen Rückruf an das Orchestration-Tool der Drittpartei zu senden. Dieser Genehmigungs-Flow wartet, bis die Change-Anforderung den Status Implementieren erreicht. Sobald die Change-Anforderung den Status „Implementieren“ erreicht hat, aktualisiert dieser Flow den Datensatz der Schrittausführung in den entsprechenden Status (genehmigt, abgelehnt, storniert). Sobald der Schrittausführungsdatensatz aktualisiert wird, wird der Flow „Rückruf für Change-Steuerung“ ausgelöst, um den Rückruf an das Drittanbieter-Tool zu senden.
Nach dem Upgrade
- Das Feld Change-Modell wird im Schrittformular angezeigt. Dies hat keine Auswirkungen auf Ihren vorhandenen typbasierten Change-Erstellungsprozess, da die Typkompatibilitätseigenschaft (com.snc.change_management.change_model.type_compatibility) auf „wahr“ festgelegt ist.
- Wenn Sie eine modellbasierte Change-Anforderung wünschen, legen Sie die Typkompatibilitätseigenschaft auf false fest. Das Feld „Change-Modell“ im Formular „Schritt“ ist erforderlich. Informationen zur Konfigurationskombination basierend auf der Eigenschaft finden Sie in Tabelle Wenn die Typkompatibilitätseigenschaft auf False festgelegt ist.
Hinweis:
Wenn Sie bereits Kunde sind und Ihre Instanz mit zbooted gestartet haben, oder ein neuer Kunde, können Sie standardmäßig modellbasierte Change-Anforderungen erstellen. Sie können jedoch typbasierte Change-Anforderungen erstellen, indem Sie die Typkompatibilitätseigenschaft auf true festlegen.
In der folgenden Tabelle wird erläutert, wie die Funktion „Change-Modell“ für neue Kunden und Kunden funktioniert, die Upgrades durchführen.
| Neue Instanz oder Upgrade-Instanz | Typ-Kompatibilitätskennzeichnung | Modell oder Typ | Statusübergangs-Flows | Genehmigungs-Flows für automatischen Change | Rückruf an Drittpartei |
|---|---|---|---|---|---|
| zboot (neues oder vorhandenes zbooted) | falsch | DevOps-Modell |
|
Im Basissystem erfolgt die Change-Genehmigung (automatisch oder manuell) über den Flow Change-Anforderung – DevOps – Bewerten. Wenn Sie eine andere Genehmigungsebene wünschen, können Sie den Flow Change-Anforderung – DevOps – Autorisieren lesen und die DevOps-Modell-Change-Richtlinie entsprechend anpassen. | Siehe Hinweis im Abschnitt „Rückruf“. |
| Upgrade | falsch | DevOps-Modell |
|
Im Basissystem erfolgt die Change-Genehmigung (automatisch oder manuell) über den Flow Change-Anforderung – DevOps – Bewerten. Wenn Sie eine andere Genehmigungsebene wünschen, können Sie den Flow Change-Anforderung – DevOps – Autorisieren lesen und die DevOps-Modell-Change-Richtlinie entsprechend anpassen. | Siehe Hinweis im Abschnitt „Rückruf“. |
| zboot (neues oder vorhandenes zbooted) | falsch | Vereinfachtes DevOps-Modell |
|
Im Basissystem erfolgt die Change-Genehmigung (automatisch oder manuell) über den Flow Change-Anforderung – DevOps – Autorisieren. Wenn Sie eine andere Genehmigungsebene wünschen, können Sie die Change-Richtlinie für vereinfachte DevOps-Modelle entsprechend anpassen. | Siehe Hinweis im Abschnitt „Rückruf“. |
| Upgrade | falsch | Vereinfachtes DevOps-Modell |
|
Im Basissystem erfolgt die Change-Genehmigung (automatisch oder manuell) über den Flow Change-Anforderung – DevOps – Autorisieren. Wenn Sie eine andere Genehmigungsebene wünschen, können Sie die Change-Richtlinie für vereinfachte DevOps-Modelle entsprechend anpassen. | Siehe Hinweis im Abschnitt „Rückruf“. |
| Upgrade | wahr | Typ | Das aktuelle Verhalten wird fortgesetzt | Flows für manuelle Genehmigung von DevOps-Change-Anforderungen, oder von DevOps-Change-Anforderungen mit minimaler Automatisierungsgenehmigung oder von DevOps-Change-Anforderungen für erweiterte Automatisierungs-Genehmigungen (je nachdem, welcher Flow aktiv ist) | Flows für Rückruf der Change-Steuerung |