Aufgabentrennung bei Beförderungen

• Beförderungen, die in erster Linie durch den Pull-Request-Workflow erreicht wurden

  • → PR zur Promotion erstellen (z. B. vom Quell- zum Ziel-Env-Zweig)
  • → PR prüfen/bearbeiten (einschließlich Überprüfung des Validierungsstatus des PR)
  • → PR in den Ziel-Env-Zweig einbinden
  • → CD-Bereitstellungspipeline ausführen (bei Commit, per Timer oder manuell)
  • → Das Gleiche gilt für den nächsten Umgebungszweig
  • → Es kann eine beliebige Anzahl von Umgebungszweigen geben

• Rollen

  • Entwickler: Code committen, wodurch die CI-Pipeline den Hauptbestand (Nicht-Produktionsbestand) aktualisiert
  • Promotion Ops / Release Manager: Auslösen der Promotion-Pipeline (Main → Staging und/oder Staging → Prod), Erstellen von Pull-Requests mit Statusprüfung für das Gating (durchgesetzt durch Toolchain-ACLs und Schutzmaßnahmen für Inventar-Branches)
  • Produktionsbetrieb / Genehmiger: Überprüfen und Zusammenführen des Promotion-PR in den Produktionszweig. Produktionspipelines ausführen. (durch Schutz des Inventory-Zweigs erzwungen)

• Nutzen Sie unterschiedliche CD-Toolchains für Staging- und Produktions-Workloads (unterschiedliche Ops)

• Das bedeutet, dass ein Entwickler zwar eine Änderung vorbereiten kann, diese jedoch nicht einseitig in die Produktion übernehmen darf, wenn der Branch-Schutz einen separaten Genehmiger erfordert.

• Die PR für die Bereitstellung dient als offizielles Protokoll zur Genehmigungsänderung, und der Merge-Verlauf liefert nachprüfbare Nachweise darüber, wer die Bereitstellung in der Produktion wann genehmigt hat.

Schritte für die Promotion-Pipeline

1. Holen Sie sich Rückmeldungen zur Promotion und zum Pull- oder Merge-Request für die Promotion.
2. Stufen Sie die Bestandseinträge aus der Quellenumgebung in die Zielumgebung um.
3. Erstellen Sie den Pull- oder Merge-Request für die Promotion. Bearbeiten Sie die Pull-/Zusammenführungsanforderung, um anzugeben, welche Änderungen ausgeführt werden sollen. Achten Sie auf optionale und obligatorische Felder
4. Optional. Legen Sie die Angabenstatus fest und fügen Sie die Zusammenfassung der zusammengefassten Angaben zur Pull-/Zusammenführungsanforderung für Werbeaktionen hinzu.
5. Führen Sie die Pull-/Merge-Anforderung zusammen.
6. Eine Slack-Benachrichtigung senden, wenn die Funktion aktiviert ist.

Stages und Tasks

In der folgenden Tabelle sind die Aufgaben aufgeführt, die in einer Promotion-Pipeline ausgeführt werden. Darüber hinaus bietet die Tabelle einen Überblick über jede dieser Phasen:

• Aufgabe oder Phase: Dies bezieht sich auf den Namen der Phase, wie er in der .pipeline-config.yaml Konfigurationsdatei definiert ist.

• Kurzbeschreibung: Hier wird kurz erläutert, welche Aktionen während der Ausführung der Phase durchgeführt werden.

• Anpassung zulässig: Hier wird angegeben, ob Benutzer die Möglichkeit haben, das Standardverhalten der Stufe durch Einfügen eines benutzerdefinierten Skripts in die Datei .pipeline-config.yaml zu ändern oder zu ersetzen.

• Standard-Referenzimplementierung: Gibt an, ob die DevSecOps-Pipelines eine vordefinierte oder Standardimplementierung für die jeweilige Stufe enthalten. Insbesondere für bestimmte Phasen wie oder unit-tests``setup bietet die DevSecOps-Pipeline keine sofort einsatzbereite Implementierung. Stattdessen müssen Nutzer eigene Skripte oder Code bereitstellen, die auf die Anforderungen ihrer Anwendung zugeschnitten sind.

• Beweissicherung: Hier wird angegeben, ob in dieser Phase die Erfassung von Standardbeweisen erfolgt. Wenn die DevSecOps-Pipeline eine Referenzimplementierung für eine Phase bereitstellt, erfolgt die Beweissicherung sofort und ohne zusätzliche Konfiguration. Sollten Nutzer diese vordefinierten Phasen jedoch ändern oder ersetzen wollen, müssen sie sicherstellen, dass ihre benutzerdefinierten Implementierungen eine angemessene Beweissicherung beinhalten. Die gleiche Verantwortung obliegt den Benutzern in Phasen, in denen die DevSecOps-Pipeline keine sofort einsatzbereite Implementierung bereitstellt, sodass sie selbst Beweismittel sammeln müssen. Die Spalte gibt die Instanz ( Benutzer/Pipeline ) an, die für die Durchführung der Beweissicherung zuständig ist.

• Überspringen zulässig (gilt für Version >= v10 ): Gibt an, ob Benutzer die Ausführung dieser Phase deaktivieren können, indem sie die Eigenschaft skip in der Datei auf true setzen .pipeline-config.yaml. Bei der Nutzung dieser Funktion ist jedoch Vorsicht geboten, insbesondere bei Phasen, die der Beweissicherung dienen. Das Überspringen solcher Schritte könnte dazu führen, dass wichtige Nachweise für den Build fehlen.

Weitere Informationen dazu, wie Sie Phasen mithilfe der Datei .pipeline-config.yaml anpassen können, finden Sie unter Benutzerdefinierte Skripte und Liste der Pipeline-Parameter.

Promotion-Pipeline ausführen

Verwenden Sie den Auslöser für die manuelle Umstufung, um die Promotion-Pipeline auszuführen. Wenn der Quell- (Master-)Zweig dem Ziel- (Prod-)Zweig voraus ist, erstellt die Pipeline eine Pull- oder Merge-Anfrage zur Übertragung, die Sie überprüfen und bearbeiten können. Wenn die Quellenverzweigung nach dem Ziel kommt, schlägt die Promotion-Pipeline mit der Nachricht fehl, dass All changes have already been promoted.

Um die Standardwerte des Pull-/Merge-Requests für die Promotion zu ändern oder die Promotion von einer alternativen Quelle zum Ziel durchzuführen, können Benutzer die Eingaben über die Benutzeroberfläche Pipeline-Umgebungsvariablen anpassen.

Bevor Sie die Pipeline für die kontinuierliche Bereitstellung ausführen, stellen Sie sicher, dass der Pull-/Merge-Request für die Promotion zusammengeführt wurde. Sie finden die Pull-/Merge-Anfrage URL in den Pipeline-Protokollen.

Weitere Informationen zum Bestands- und Umstufungsprozess finden Sie im Abschnitt zur Bestandsumstufung.

Lagerartikel teilweise bewerben

Mit der Methode der teilweisen Werbung kann die Werbepipeline eine ausgewählte Teilmenge des verfügbaren Inventars bewerben.

Ein Inventareintrag wäre in diesem Zusammenhang eine einzelne Datei (des Inventartyps) im Inventar-Repo; diese würde einem eindeutigen Dateinamen im lokalen Dateisystem {: important}zugeordnet werden.

Verwenden der Parameter inventory-include Und inventory-exclude aktiviert die Methode der teilweisen Beförderung.

Beim Benutzen inventory-include, die in dieser Umgebungseigenschaft angegebenen Muster/Dateinamen werden in die entsprechenden Einträge aufgelöst und von der Pipeline weitergeleitet. Ebenso können Einträge in inventory-exclude von der Aktion ausgeschlossen werden.

Das Format verwendet das Glob-Muster (unterstützt auch vollständige Pfade), ähnlich dem, was in der CC-Pipeline befolgt wird. Weitere Informationen zu Glob-Mustern finden Sie im Globus Handbuch.

cd-pipeline-deps
my-application-plugin-component-config
my-application-plugin-component-diagnostic-monitor
configuration # directory entry
configuration/my-staging-region # directory entry
configuration/my-staging-region/environment-1-cluster # directory entry
configuration/my-staging-region/environment-1-cluster/serviceA-component_config
configuration/my-staging-region/environment-1-cluster/serviceB-system_config
configuration/my-staging-region/environment-1-cluster/serviceC-params_config
configuration/serviceX-dashboard-setup_helm
configuration/serviceY-releases_helm
my-application-task-runner
my-application-dashboard
my-application-dashboard_deployment
my-application-module
my-application-module_deployment
.inventoryignore
global_deployment
README.md

    my-application-plugin-component-config
    my-application-plugin-component-diagnostic-monitor

    configuration/serviceX-dashboard-setup_helm
    configuration/serviceY-releases_helm

    configuration/my-staging-region/environment-1-cluster/serviceA-component_config
    configuration/my-staging-region/environment-1-cluster/serviceB-system_config
    configuration/my-staging-region/environment-1-cluster/serviceC-params_config

    my-application-dashboard
    my-application-dashboard_deployment

    my-application-plugin-component-config
    my-application-plugin-component-diagnostic-monitor
    configuration/serviceX-dashboard-setup_helm
    configuration/serviceY-releases_helm

    cd-pipeline-deps
    my-application-plugin-component-config
    my-application-plugin-component-diagnostic-monitor
    my-application-task-runner
    my-application-module
    my-application-module_deployment
    .inventoryignore
    global_deployment

Hochstufungs-/Zusammenführungsanforderungen

Die Informationen aus dem Hauptteil des Pull-/Merge-Requests der Promotion werden zur Erstellung des Änderungsantrags verwendet. Dateien, die durch den Pull-/Merge-Request im Rahmen der Promotion geändert werden, stellen die Einträge dar – beispielsweise Images –, die von der Continuous-Deployment-Pipeline bereitgestellt werden. Wurden die Änderungen aufgrund eines Notfalls vorgenommen, wird der Pull- oder Merge-Request für die Promotion mit einem Notfall-Label gekennzeichnet. Der von der Continuous-Deployment-Pipeline erstellte Änderungsantrag wird ebenfalls als gekennzeichnet emergency.

Die in der Pipeline für kontinuierliche Integration erfassten Angaben werden zusammengefasst und an die Änderungsanforderung in der Pipeline für kontinuierliche Bereitstellung angehängt.

Pipeline für Hochstufungsvalidierung

Nachdem eine Werbeaktions-PR geöffnet wurde, können Sie optional die Angabenaggregation und die Zusammenfassungsgenerierung in der Werbeaktionsvalidierungspipeline ausführen und die Angabenstatus für die Werbeaktions-Pull-/Zusammenführungsanforderung festlegen. Die Bedarfsanforderung kann von der Promotion-Pipeline oder manuell im Bestandsrepository erstellt werden.

Die Pipeline ermöglicht die frühzeitige Validierung der Werbeaktionsbedarfsanforderung, bevor die Bedarfsanforderung mit der Zielverzweigung (Umgebung) zusammengeführt wird. Basierend auf dem Status der Bedarfsanforderung können Benutzer entweder mit der Werbeaktion fortfahren (wenn alle Angabenstatus grün sind) oder das Problem in der Pipeline für kontinuierliche Integration beheben (wenn der Angabenstatus rot ist).

Darüber hinaus fügt die Validierungspipeline auch die aggregierte Zusammenfassung der Nachweise für eine oder mehrere Anwendungen im Inventar als Kommentar in einem benutzerfreundlichen Tabellenformat (wie in Abbildung 3 dargestellt) zum Pull-/Merge-Request für die Promotion hinzu. Die Tabelle enthält nützliche Links, beispielsweise zu Pipeline-Läufen, App-Repositorys und Issues, die für jede der Anwendungen erstellt wurden.

Standardmäßig entspricht jede Zeile in der Tabelle „Detaillierter Beweisstatus“ einem Anwendungskontext, der von einem Quell-Repository bereitgestellt wird, das zur Erstellung von Artefakten verwendet wird, auf die in den Inventareinträgen verwiesen wird. Diese Standardgruppierung der Anwendung kann auf der Grundlage eines Gruppierungswerts angepasst werden, der durch Anwendung des JSON-Filters (definiert in der Eigenschaft application-group-by-filter) auf jede Inventareintragungsdatei ermittelt wird.

Während die Validierung in Bearbeitung ist, wird die Zusammenführung der Pull-/Zusammenführungsanforderung für Werbeaktionen blockiert. Nach Abschluss der Validierungspipeline wird der Angabenstatus in der Pull-/Zusammenführungsanforderung festgelegt. Durch Klicken auf jeden Eintrag im Status wird der Benutzer zur jeweiligen Phase in der entsprechenden CI-Pipelineausführung geführt.

Stages und Tasks

In der folgenden Tabelle sind die Aufgaben aufgeführt, die in einer Promotion-Validierungs-Pipeline ausgeführt werden. Darüber hinaus bietet die Tabelle einen Überblick über jede dieser Phasen:

• Aufgabe oder Phase: Dies bezieht sich auf den Namen der Phase, wie er in der .pipeline-config.yaml Konfigurationsdatei definiert ist.

• Kurzbeschreibung: Hier wird kurz erläutert, welche Aktionen während der Ausführung der Phase durchgeführt werden.

• Anpassung zulässig: Hier wird angegeben, ob Benutzer die Möglichkeit haben, das Standardverhalten der Stufe durch Einfügen eines benutzerdefinierten Skripts in die Datei .pipeline-config.yaml zu ändern oder zu ersetzen.

• Standard-Referenzimplementierung: Gibt an, ob die DevSecOps-Pipelines eine vordefinierte oder Standardimplementierung für die jeweilige Stufe enthalten. Insbesondere für bestimmte Phasen wie oder unit-tests``setup bietet die DevSecOps-Pipeline keine sofort einsatzbereite Implementierung. Stattdessen müssen Nutzer eigene Skripte oder Code bereitstellen, die auf die Anforderungen ihrer Anwendung zugeschnitten sind.

• Beweissicherung: Hier wird angegeben, ob in dieser Phase die Erfassung von Standardbeweisen erfolgt. Wenn die DevSecOps-Pipeline eine Referenzimplementierung für eine Phase bereitstellt, erfolgt die Beweissicherung sofort und ohne zusätzliche Konfiguration. Sollten Nutzer diese vordefinierten Phasen jedoch ändern oder ersetzen wollen, müssen sie sicherstellen, dass ihre benutzerdefinierten Implementierungen eine angemessene Beweissicherung beinhalten. Die gleiche Verantwortung obliegt den Benutzern in Phasen, in denen die DevSecOps-Pipeline keine sofort einsatzbereite Implementierung bereitstellt, sodass sie selbst Beweismittel sammeln müssen. Die Spalte gibt die Instanz ( Benutzer/Pipeline ) an, die für die Durchführung der Beweissicherung zuständig ist.

• Überspringen zulässig (gilt für Version >= v10 ): Gibt an, ob Benutzer die Ausführung dieser Phase deaktivieren können, indem sie die Eigenschaft skip in der Datei auf true setzen .pipeline-config.yaml. Bei der Nutzung dieser Funktion ist jedoch Vorsicht geboten, insbesondere bei Phasen, die der Beweissicherung dienen. Das Überspringen solcher Schritte könnte dazu führen, dass wichtige Nachweise für den Build fehlen.

Weitere Informationen dazu, wie Sie Phasen mithilfe der Datei .pipeline-config.yaml anpassen können, finden Sie unter Benutzerdefinierte Skripte und Liste der Pipeline-Parameter.

Wie kann die Validierung von Werbeaktionen aufgenommen werden?

Veraltet Die Option opt-in-promotion-validation, die verwendet wurde, um die Validierungspipeline für Beförderungen bei einer Pull-Anfrage automatisch zu starten, ist deprecated zugunsten der Option Git Promotion Validation trigger. Wenn Sie diese Eigenschaft in den Umgebungseinstellungen haben, wird der Hinweis zur Einstellung der Unterstützung in den Pipelineprotokollen und in der Slack-Benachrichtigung angezeigt.

Wie kann man die Validierung von Werbeaktionen aktivieren?

Für alle neuen CD-Toolchains wird automatisch ein Trigger namens Git-Promotion-Validierung erstellt und aktiviert.

Um den Auslöser Git-Hochstufungsvalidierung für eine vorhandene Pipeline zu aktivieren, können Sie die folgenden Schritte ausführen.

1. Rufen Sie die Seite Auslöser der CD-Pipeline auf, der Sie sie hinzufügen möchten.
2. Wählen Sie Hinzufügen > Git-Repository aus, um einen neuen Auslöser hinzuzufügen.
3. Geben Sie die folgenden Informationen ein, die für den Auslöser erforderlich sind:
   • Geben Sie einen Auslösernamen an. Beispiel: Git-Auslöser für die Werbeaktionsvalidierung.
   • Geben Sie promotion-validation-listener or promotion-validation-listener-gitlab als EventListener an.
   • Wählen Sie das entsprechende Bestandsrepository für die Pipeline für das Feld Repository aus.
   • Wählen Sie den Namen der Zielumgebung für die Verzweigung aus.
   • Wählen Sie das Feld Beim Öffnen oder Aktualisieren einer Pull-Anforderung aus.
4. Klicken Sie auf Hinzufügen.
5. Setzen Sie den Auslöser auf Ein.

Eingaben

Ausgänge und Auswirkungen

• Slack-Benachrichtigung
• Hochstufungs-/Zusammenführungsanforderung

Sie müssen die Pull-/Merge-Anforderung bearbeiten und ändern, wenn die optionalen Parameter nicht angegeben wurden.

Wenn die (optionale) BA-Validierung der Werbeaktion ausgeführt wird, wird der Angabenstatus in der Pull-/Merge-Anforderung festgelegt.

Die zusammengefasste Angabenzusammenfassung der Angaben (die aus mehreren Apps im Bestand stammen können) wird im Tabellenformat als Kommentar in der Bedarfsanforderung angezeigt.

Nächster Schritt

Nachdem die Promotion Pipeline erfolgreich beendet wurde, können Sie mit der CD-Pipeline fortfahren.