Bewertung der Einsatzbereitschaft vor der Entsendung

Bevor eine Änderungsanforderung erstellt wird, berechnet die Pipeline die Bereitschaft für die Bereitstellung und setzt das Kennzeichen DEPLOYMENT_READY auf true oder false. Diese Kennzeichnung wurde aus Nachweisen abgeleitet, die in den Phasen CI und CD gesammelt wurden. Wenn eine Evidenzprüfung eine Abweichung, eine fehlende oder nicht erfolgreiche Prüfung, einen Scan oder einen Test in Bezug auf die eingesetzte Artefaktmenge anzeigt, wird DEPLOYMENT_READY auf false gesetzt.

Der Änderungsantrag wird mit den folgenden Feldern vorbereitet, die aus dem letzten zusammengefassten Promotion-PR im Zielzweig stammen:

• risk
• impact
• priority
• assignee
• description
• purpose
• customer impact
• deployment impact
• backout plan

Erstellung eines Änderungsantrags

Der vorbereitete Änderungsantrag wird in Abhängigkeit von DEPLOYMENT_READY in einem von zwei Ausgangszuständen eingereicht:

Das Änderungsmanagementsystem genehmigt auch automatisch Änderungsanträge, wenn die Implementierung keine Ausfallzeiten verursacht (die Ausfalldauer ist gleich Null) und DEPLOYMENT_READY true ist und das Implementierungsrisiko innerhalb akzeptabler Grenzen liegt.

Wenn für Ihre Änderungen eine geplante Ausfallzeit erforderlich ist, müssen Sie die Änderungsanfrage manuell erstellen und sie zwecks Genehmigung einreichen. Nachdem sie genehmigt worden ist, können Sie mit der Bereitstellung beginnen, indem Sie die ID für die Änderungsanfrage angeben. Die Pipeline prüft ihren Genehmigungsstatus und führt dann die Bereitstellung aus. Weitere Informationen finden Sie unter Änderungsanforderungen manuell genehmigen.

Anhänge vor der Entsendung

Unmittelbar nach der Erstellung des Änderungsauftrags fügt die Pipeline die folgenden Artefakte an den CR-Datensatz an:

• Bereitstellungsstückliste- listet alle in der Bereitstellung enthaltenen Komponenten auf
• Delta-Zusammenfassung- Nachweis der Lage aller an der Bereitstellung beteiligten Komponenten
• Evidence Checks Config File- nur angehängt, wenn die auf Evidence Checks basierende Ansteuerung in der Pipeline konfiguriert ist
• SCC-Profil- nur angehängt, wenn eine Sicherheits- und Compliance-Konfiguration konfiguriert ist

Zulassungsstelle

Wurde die Änderungsanforderung als "Nicht genehmigt" erstellt, wird sie in einen nicht genehmigten Zustand versetzt und zur Überprüfung an einen Mitarbeiter geschickt. Der Einsatz erfolgt erst, wenn die Genehmigung erteilt wurde.

Sie können die generierte Änderungsanforderungs-ID den Pipeline-Protokollen entnehmen, auf die Genehmigung warten und anschließend die Bereitstellung unter Verwendung derselben Änderungsanforderungs-ID neu starten. Die Pipeline prüft den Genehmigungsstatus und setzt die Bereitstellung fort.

Einführungs- und Abnahmetests

Wenn sich die CR im Zustand Implementiert befindet, wird die Pipeline ausgeführt:

• CD-Deployment- Bereitstellung von Code in der Zielumgebung
• Abnahmetests- validiert das Ergebnis der Bereitstellung

Bei diesen beiden handelt es sich um benutzergesteuerte Laufphasen.

Abschluss der CR nach der Entsendung

Wenn die Bereitstellungs- und Akzeptanztests bestanden sind, fügt die Pipeline die abschließenden Artefakte hinzu und schließt die Änderungsanforderung ab:

• Abschlusszusammenfassung- eine Zusammenfassung der Belege für alle Bestandseinträge auf der Ebene der Zielbindung.
• Zusammengeführte SBOM- die Software-Stückliste nach der Bereitstellung für alle Komponenten im Inventar.

Der CR wird dann mit einer close_category auf der Grundlage von DEPLOYMENT_READY zum Zeitpunkt des Abschlusses geschlossen:

Änderungstypen

Das Änderungsanforderungsmanagement unterstützt zwei Arten von Änderungen: Notfalländerungen und reguläre Änderungen.

Wenn es sich bei der aktuellen Änderung um eine Notfalländerung handelt, füge dem Pull-Request für die Promotion das Label „ emergency “ hinzu.

Auf der Seite der CI-Pipeline gibt es keinen Notstrom. Wenn Sie jedoch die CI-Pipeline/Trigger-Eigenschaft skip-inventory-update-on-failure auf einen leeren Wert oder 0 setzen, kann das Inventar-Repository auch dann aktualisiert werden, wenn während des CI-Pipeline-Laufs Probleme entdeckt werden. Mit diesem aktualisierten Inventar kann eine Notfalländerung aktiviert werden.

Wahl eines Verwertungsweges

Pfad 1: Vollständiges Rollback unter Verwendung des dedizierten Rollback-Listeners

Wenn eine "last-known-good"-Konfiguration vorhanden ist, d. h. ein früherer Zustand, der sich als stabil erwiesen hat, ist der schnellste Weg zur Wiederherstellung des Dienstes ein vollständiges Rollback. Dabei wird ein spezieller Rollback-Listener verwendet, der speziell für dieses Szenario entwickelt wurde und kein neues Build oder keine Promotion erfordert.

Eine schrittweise Anleitung und die zu konfigurierenden Parameter finden Sie unter Vollständiges Rollback mit dem dedizierten Rollback-Listener.

Weg 2: Fix-forward als Notfalländerung

Wenn es kein brauchbares Rollback-Ziel gibt oder wenn die Untersuchung bereits zu einem Patch geführt hat, kann die Korrektur als Notfalländerung eingespielt werden. Dieser Weg umgeht die standardmäßige Evidence-Gating-Logik: Die Pipeline ermöglicht die sofortige Implementierung der Änderung, und die Änderungsanforderung unterliegt einer rückwirkenden Überprüfung und Genehmigung, nachdem der Vorfall behoben wurde.

Wenn Sie diesen Weg wählen, müssen Sie akzeptieren, dass der Code, der in der Produktion eingesetzt wird, noch ungelöste Schwachstellen oder offene Beweislücken enthalten kann. Die Wiederherstellung des Dienstes wird als höhere Priorität behandelt, und die noch ausstehenden Aufgaben müssen nach Abschluss des Vorfalls erledigt werden.

Diese beiden Wege schließen sich nicht gegenseitig aus. In der Praxis kann es vorkommen, dass Teams zunächst ein vollständiges Rollback einleiten, um den Dienst sofort wiederherzustellen, und dann ein Fix-Forward folgen lassen, sobald der Patch fertig und validiert ist. Die Reihenfolge ist dem Urteil des Bedieners je nach Situation überlassen.

Fix-Forward-Verfahren

Führen Sie die folgenden Schritte aus, um eine Korrektur als Notfalländerung während einer CIE bereitzustellen:

1. Bauen Sie die betroffene Komponente neu auf. Führen Sie die CI-Pipeline aus, um eine neue Artefaktversion zu erstellen, die die Korrektur enthält. Wenn CI-Evidenzprüfungen aufgrund von Störfallbedingungen fehlschlagen, setzen Sie die Pipeline- oder Triggereigenschaft skip-inventory-update-on-failure auf einen leeren Wert oder 0, damit das Inventar trotz der Fehlschläge aktualisiert werden kann, so dass die Notfalländerung fortgesetzt werden kann.

2. Fördern Sie die Lösung durch die Umgebung. Erstellen Sie Pull Requests für Promotions, beginnend mit der niedrigsten Umgebung und steigern Sie diese in Richtung Produktion. Wenn es die Zeit erlaubt, überprüfen Sie die Korrekturen in jeder Phase, bevor Sie weiter vorgehen. Wenn die Situation kritisch ist, schalten Sie direkt in die Produktion um und gleichen Sie niedrigere Umgebungen ab, nachdem der Betrieb wiederhergestellt ist.

3. Bringen Sie das Notfalletikett an. Fügen Sie dem Pull Request für die Produktion das Label emergency hinzu. Dies signalisiert der Pipeline, dass das Standard-Evidence-Gating umgangen und die Änderung als Notfalleinsatz behandelt werden sollte.

4. In die Produktion einführen. Führen Sie die CD-Pipeline aus. Die Pipeline erkennt die Notfallkennzeichnung, überspringt die Wartezeit auf die Genehmigung und geht sofort zu den Bereitstellungs- und Abnahmetests über. Die Änderungsanforderung wird mit close_category = successful with issues erstellt und geschlossen, um zu verdeutlichen, dass die Änderung unter Notfallbedingungen durchgeführt wurde.

5. Versöhnen Sie die unteren Umgebungen. Nachdem der Produktionsvorfall behoben ist, stellen Sie dasselbe Artefakt zur Notfallbehebung in niedrigeren Umgebungen bereit - Staging, Pre-Production usw. -, damit alle Umgebungen einen einheitlichen Zustand mit der Produktion aufweisen. Wenn niedrigere Umgebungen vor der Einführung in die Produktion überprüft wurden, stellen Sie sicher, dass auf allen Ebenen dieselbe Artefaktversion vorhanden ist.

Post-CIE-Verpflichtungen

Ein Notfalleinsatz zieht Verpflichtungen zur Einhaltung der Vorschriften nach sich, die nach Abschluss des Vorfalls erfüllt werden müssen:

• Der Änderungsantrag muss rückwirkend von den zuständigen Genehmigern geprüft und genehmigt werden.
• Alle während des Notfalls akzeptierten Beweislücken - nicht behobene Schwachstellen, unvollständige Scans oder fehlgeschlagene Prüfungen - müssen behoben und die Pipeline unter Standardbedingungen erneut ausgeführt werden.
• Es sollte eine Ursachenanalyse (RCA) durchgeführt und dokumentiert werden.

Der Datensatz der Änderungsanforderung, einschließlich der von der Pipeline angehängten Delta Summary, Closing Summary und Merged SBOM, dient als primärer Prüfpfad für die Post-CIE-Prüfung.

Aufrufen des Notstroms

Der Notfallfluss wird vom Benutzer initiiert:

1. Der Benutzer führt die Pipeline mit dem Label emergency aus, das auf die Pull-Anforderung für die Promotion angewendet wird.
2. Die Pipeline erkennt die Notfallbezeichnung und die Einsatz- und Abnahmetests werden sofort durchgeführt, ohne auf die Standardgenehmigung zu warten.
3. Der CR wird mit den Schlussbemerkungen unter successful with issues geschlossen.

Wenn es sich bei der aktuellen Änderung um eine Notfalländerung handelt, füge dem Pull-Request für die Promotion das Label „ emergency “ hinzu, bevor du die Pipeline ausführst.

Einsatz nach einem Notfall

Sobald der Notfallablauf die Einrichtung und die Tests abgeschlossen hat, wird er in der Phase nach der Einrichtung wieder in den Standardablauf integriert:

• Closing Summary und Merged SBOM sind dem CR beigefügt.
• Die CR wird nach der gleichen DEPLOYMENT_READY-basierten close_category Logik geschlossen wie der Standardablauf.

Wenn der CR-Typ emergency ist, muss der Änderungsantrag nach der Bereitstellung rückwirkend überprüft und genehmigt werden.

Auslösende Bedingung

Der Inline-Rollback-Fluss wird eingeleitet, wenn die Bereitstellungs- oder Akzeptanztests nicht bestanden werden. Die Pipeline prüft dann, ob das Inline-Rollback aktiviert ist:

• Inline-Rollback nicht aktiviert: Die CR wird mit close_category = unsuccessful offen gelassen und die Pipeline wird beendet. Es wird keine automatische Wiederherstellung versucht.
• Rollback aktiviert: Das Rollback-Skript wird ausgeführt, um die Zielumgebung wiederherzustellen, und die Rollback-Artefakte werden gesammelt und an die CR angehängt.

Inline-Rollback-Ausführung

Wenn Inline-Rollback aktiviert ist, wird die Pipeline:

1. Führt das Inline-Rollback-Skript aus, wenn die Bereitstellung oder der Akzeptanztest in der CD-Pipeline fehlgeschlagen ist.
2. Sammelt die folgenden Artefakte:
   • Rollback-Protokolle- Ausgabe der Ausführung des Rollback-Skripts
   • Abschlusszusammenfassung- spiegelt das Ergebnis des Rollbacks wider
   • Zusammengeführte SBOM- Post-Rollback-Software-Stückliste
3. Hängt alle drei Artefakte an den offenen CR-Datensatz an.

CR-Abschluss nach Rollback

Nach Inline-Rollback und Artefaktanhang bleibt der CR mit close_category = unsuccessful offen. Dies signalisiert dem Änderungsmanagement, dass die Bereitstellung versucht wurde, fehlgeschlagen ist und automatisch rückgängig gemacht wurde.

Ein CR mit close_category = unsuccessful ist das erwartete und korrekte Ergebnis, wenn ein Einsatz rückgängig gemacht wird - kein Hinweis auf einen Prozessfehler. Die Betriebsteams sollten die beigefügten Rollback-Protokolle verwenden, um die Ursache zu untersuchen.

Laufende Pipeline mit einer vorab genehmigten Änderungsanforderung

Sie können eine vorab genehmigte Änderungsanforderung (CR) für die Bereitstellung verwenden. Zwei Szenarien sind möglich:

Wenn die CD-Pipeline erkennt, dass die CR durch einen früheren Lauf der CD-Pipeline erstellt wurde, leitet sie die Bereitstellung über einen Schnellpfad weiter:

• Wiederverwendung des vorberechneten Deltas und der Evidenzzusammenfassung aus der CR-Evidenz.
• Überspringen der Schritte zur Begutachtung durch Fachkollegen und zur Überprüfung der Unterschrift.
• Bereitstellung des vorberechneten Deltas.

Wenn die CD-Pipeline nicht feststellen kann, ob die CR von einem früheren CD-Pipeline-Lauf erstellt wurde, oder die bereitgestellte CR nicht mit dem Bereitstellungsziel des aktuellen Laufs übereinstimmt:

• Es werden keine vorberechneten Delta- oder Evidenz-Zusammenfassungen wiederverwendet.
• Die Überprüfung durch Fachkollegen oder die Überprüfung der Artefaktsignatur wird nicht übersprungen.
• Er berechnet Delta und Zusammenfassung von Grund auf neu.
• Es wird keine neue CR erstellt, da bereits eine geliefert wurde.

Wiederholung der Pipeline bei einer fehlgeschlagenen Bereitstellung

Wenn Sie das automatisierte Änderungsmanagement nicht nutzen möchten, können Sie stattdessen einen zuvor erstellten und genehmigten Änderungsantrag vorlegen. Führen Sie fehlgeschlagene Bereitstellungen in den folgenden Szenarios erneut aus:

• Der zuletzt automatisch erstellte Änderungsantrag ist noch nicht bereit für die Bereitstellung und wurde nicht automatisch genehmigt. Sie haben die Genehmigung erhalten und müssen die Bereitstellung mit demselben Änderungsantrag neu starten.
• Für die Bereitstellung fallen Ausfallzeiten an. Sie haben den Änderungsantrag erstellt, er wurde genehmigt, und Sie haben die Änderungsmanagementrichtlinie Ihres Unternehmens befolgt.
• Es wurden keine Änderungen am Code oder an der Konfiguration vorgenommen. Sie haben den Änderungsantrag erstellt, die Änderungen erläutert, die Genehmigung erhalten und eine Bereitstellung unter Verwendung des genehmigten Änderungsantrags gestartet.

Der Änderungsantrag (CR) bleibt nach Abschluss der CD-Pipeline offen.

Sie können die Referenz-Pipeline für kontinuierliche Bereitstellung von „ DevSecOps “ starten, indem Sie einen vorab genehmigten Änderungsantrag verwenden und die Änderungsantrags-ID in die Eigenschaft „change-request-id“ eingeben.

Wenn die Eigenschaft „change-request-id“ gesetzt ist, überspringt die Pipeline die Datenerfassung für den Änderungsantrag und fährt mit der Überprüfung des Genehmigungsstatus fort. Wenn „change-request-id“ standardmäßig auf „ notAvailable “ gesetzt ist, wird von der Pipeline automatisch ein Änderungsantrag erstellt.