Automatisiertes Änderungsmanagement
Die Automatisierung des Änderungsmanagements ist ein wichtiger Teil der Referenzimplementierung der DevSecOps Pipeline. Entwickler, Genehmiger und Prüfer können die Compliance-Aspekte von Bereitstellungen überwachen. Jede Bereitstellung muss der Änderungsverwaltungsrichtlinie einer Organisation entsprechen.
Die Pipelines erfassen Nachweise aus jedem Teil des Build- und Bereitstellungslebenszyklus. Jedes Beweisstück korreliert mit einem bestimmten Aufbau und Einsatz der Artefakte. Für jedes implementierte Artefakt können Sie also feststellen, ob die zugehörige Build-oder Testbereitstellung Vorfälle enthält. Diese Korrelation wird über das Bestandsmodell implementiert.
Die Verbindung zwischen Beweismitteln, Inventarisierung und Änderungsmanagement
Abbildung 1 zeigt den Datenfluss und die Verbindung zwischen Beweisen, Inventar und Änderungsmanagement.
- CI führt Build-Artefakte aus und hinterlässt Beweise dafür, was während der Erstellung dieser Artefakte passiert ist.
- Bei den CI-Ausführungsläufen werden im Bestand Einträge zu den erstellten Artefakten erstellt.
- Erstellte Artefakte im Bestand werden in Implementierungsumgebungen (wie z. B. Staging oder Vorproduktion) umgestuft.
- Die Automatisierung des Änderungsmanagements verwendet Daten aus dem Inventar, dem Beweismittelschrank und dem Promotion-PR, um die Bereitstellungen der Änderungsanforderungen zu erstellen. Der Change-Management-Automat hinterlässt beispielsweise auch Nachweise für Abnahmetests. Erfolgreich bereitgestellte und getestete Artefakte werden weiter in Produktionsumgebungen übertragen.
Für jede Bereitstellung in jeder Umgebung und Region muss eine Änderungsanforderung im Änderungsverwaltungssystem eingereicht werden. Die Änderungsmanagementautomatisierung hilft Ihnen dabei, diese Änderungsanfragen auf der Grundlage aller Nachweise und Informationen zu erstellen, die von den Pipelines erfasst werden.
Weitere Informationen finden Sie unter Änderungsmanagement automatisieren.
Reihenfolge der Änderungsmanagementbefehle
Die Reihenfolge der Änderungsanforderungsschritte lautet wie folgt:
Änderungsanforderung erstellen
Alles, was die Basislinie ändert, muss mithilfe einer Änderungsanforderung nachverfolgt werden. Zu den Änderungen zählen beispielsweise Aktualisierungen der bestehenden Codeebene, Änderungen an der Konfiguration sowie Aktualisierungen der Worker-Nodes. Das Sammeln von Peer-Review-Compliance-Daten basiert auf den Daten, die im Inventar, im Beweismittelschrank und im Vorfalls-Repository zugänglich sind.
Schließlich erstellt dieser Schritt die Änderungsanforderung, die auf den PR-Feldern für Werbeaktionen basiert, und hängt die verfügbaren Konformitätsdaten an. Die Bereitstellungsbereitschaft wird anhand des erfassten Konformitätsstatus anhand der verfügbaren Angaben berechnet.
Antrag auf Genehmigung
Wenn der Implementierungsstatus der erstellten Änderungsanforderung nicht 'Bereit' lautet, fordert dieser Schritt die Genehmigung für die Änderung an.
Auf Genehmigung prüfen
Wenn alle Konformitätsprüfungen (z. B. Komponententests, CRA-Aufgaben, Zweigschutz, Erkennung geheimer Schlüssel) erfolgreich sind, wird die Änderungsanforderung automatisch genehmigt und die Aufgabe erfolgreich ausgeführt.
Wenn eine Prüfung auf Compliance fehlschlägt, erhält die Änderungsanfrage nicht den Status 'Genehmigt'.
Sie können die Änderungsanforderung manuell genehmigen und die Änderungsanforderungs-ID zu den Umgebungseigenschaften hinzufügen, um die bereits erstellte Änderungsanforderung beim nächsten Durchlauf zu verwenden.
Eine weitere Lösung ist die Verwendung der Bezeichnung emergency in den Pull-Anforderungen für Rabatte. Weitere Informationen finden Sie unter Notfallkennzeichnung hinzufügen.
Setzen auf implement
In diesem Schritt wird der Status der Änderungsanforderung abhängig vom success-oder failure-Status der Änderung auf implement gesetzt.
Änderungsanforderung schließen
Details zur Implementierung werden in die Änderungsaufgabe "Abschlusszusammenfassung" hochgeladen und die Änderungsanforderung wird geschlossen. In der Task zum Schließen der Änderungsanforderung wird 'close_category' mit den folgenden Werten hinzugefügt:
successfulsuccessful with issues(wenn die Zusammenfassung Probleme aufweist)