Standardverhalten (ohne erzwungene Neubereitstellung)

Wenn nicht festgelegt force-redeploy oder auf false gesetzt ist, wird die Pipeline nur bereitgestellt, wenn neue Änderungen im Inventar-Repository für die Zielumgebung erkannt werden.

1. Die CD-Pipeline startet und versieht die aktuelle Übergabe mit der Lauf-ID der Pipeline.

2. Die Pipeline liest den Inhalt des entsprechenden Umgebungszweigs aus diesem Tag.

3. Die Pipeline berechnet das Bereitstellungsdelta zwischen dem aktuellen Commit und dem mit dem Tag <target-environment>_latest verbundenen Commit.

4. Die Pipeline bewertet das Delta:

   • Wenn das Delta leer ist, wird die Pipeline angehalten und es erfolgt keine Bereitstellung.
   • Wenn das Delta Änderungen enthält, wird die Pipeline fortgesetzt.

5. Die Pipeline stellt die im Delta identifizierten Änderungen bereit.

6. Nach einer erfolgreichen Bereitstellung fügt die Pipeline das <target-environment>_latest Tag zum neuen Commit hinzu.

Erzwungenes Verhalten (mit erzwungener Neuzuweisung)

Wenn auf true gesetzt force-redeploy ist, umgeht die Pipeline die Delta-Validierung und stellt das gesamte Inventar neu bereit, unabhängig von den erkannten Änderungen. Dieser Ansatz stellt sicher, dass der vollständige Anwendungsstatus erneut auf das Bereitstellungsziel angewendet wird.

1. Die CD-Pipeline startet und versieht die aktuelle Übergabe mit der Lauf-ID der Pipeline.
2. Die Pipeline liest den Inhalt des entsprechenden Umgebungszweigs aus diesem Tag.
3. Die Pipeline berechnet das Bereitstellungsdelta, das in diesem Szenario in der Regel leer ist.
4. Die force-redeploy=true Einstellung bewirkt, dass die Pipeline die Delta-Prüfung überspringt und fortfährt.
5. Die Pipeline stellt den gesamten Anwendungsstatus aus dem Branch neu bereit.
6. Nach einer erfolgreichen Neubereitstellung fügt die Pipeline das <target-environment>_latest Tag an den gerade bereitgestellten Commit an.

Übersicht über die Rollback-Pipeline

Mit dieser Pipeline können Sie zu einer früheren, bekanntermaßen funktionierenden Konfiguration zurückkehren, indem Sie eine bestimmte ServiceNow Änderungsanforderungs-ID (z. B. CHG-12345) auswählen.

Diese Änderungsanforderungs-ID dient als eindeutiges Lesezeichen für eine erfolgreiche Bereitstellung und ist eine erforderliche Eingabe für die Rollback-Pipeline.

Sie können die Änderungsanforderungs-ID für eine frühere Bereitstellung auf zwei Arten finden:

• ServiceNow: Suchen Sie die Änderungsanforderung für den Einsatz, den Sie wiederherstellen möchten.
• Inventar-Repository: Da der Status des Inventars in der Quellcodeverwaltung verwaltet wird, wird jede Bereitstellung durch einen Commit eindeutig identifiziert. Suchen Sie den Commit, den Sie rückgängig machen möchten, und identifizieren Sie den CHG-*** Tag, der mit diesem Commit verbunden ist.

Die Rollback-Pipeline umfasst die folgenden Phasen:

• prod-rollback-start
• prod-setup
• prod-rollback-change-request
• prod-deployment
• prod-acceptance-tests
• prod-rollback-finish

Der Pipeline-Lauf verwendet Informationen aus der rollback-change-request-id Umgebungseigenschaft, um eine neue Änderungsanforderung zu erstellen.

Um die Compliance aufrechtzuerhalten, öffnet die Pipeline erneut Probleme, die mit der vorherigen Bereitstellung zusammenhängen. Diese Probleme sind mit der neuen Änderungsanforderung verknüpft, und ihre ursprünglichen Fälligkeitstermine bleiben unverändert. Ein erfolgreiches Rollback verschiebt das _latest Tag im Inventar zum vorherigen Commit.

Rollback-Pipeline erstellen

Verwenden Sie die cd-rollback-listener Option, um ein Rollback auf die letzte bekannte funktionierende Version auszulösen.

1. Gehen Sie zu Ihrer CD-Pipeline.
2. Fügen Sie einen manuellen Auslöser hinzu oder duplizieren Sie den manuellen CD-Auslöser.
3. Bearbeiten Sie den Trigger und setzen Sie den Listener auf cd-rollback-listener.
4. Wählen Sie Speichern aus.
5. Erstellen Sie für jede erforderliche Kombination aus Region und Zielumgebung einen separaten Trigger.

Rollback-Pipeline auslösen

Ein Rollback-Pipeline-Lauf verwendet die folgenden Umgebungseigenschaften:

Die Pipeline wird beendet, sofern nicht die folgenden Kriterien erfüllt sind:

• rollback-change-request-id muss die ID einer abgeschlossenen Bereitstellung für dieselbe Region und Zielumgebung sein.
• Die mit verbundene Bereitstellung rollback-change-request-id darf nicht älter sein als die durch rollback-limit angegebene Anzahl von Bereitstellungen.

Die PIPELINE_NAME Tekton-Umgebungseigenschaft bestimmt, ob ein Lauf eine Bereitstellung oder ein Rollback ist.

• cd-rollback-pipeline: Standardwert für ein Rollback.
• cd-pipeline: Standardwert für eine Bereitstellung.

Mit dieser Eigenschaft können Sie die Verzweigungslogik anpassen.

Übersicht über Rollback mit GitOps

Verwenden Sie die Pipeline für kontinuierliche Bereitstellung, um eine frühere Version des Inventars in der Zielumgebung bereitzustellen, indem Sie Git Vorgänge verwenden, die Änderungen zu einem bestimmten commit-id Zeitpunkt rückgängig machen.

Da Sie Commits im Inventar-Repository direkt rückgängig machen, anstatt die Rollback-Pipeline mit einer ServiceNow Änderungsanforderungs-ID auszulösen, werden durch diesen Vorgang frühere Compliance-Probleme nicht automatisch wieder geöffnet und deren Fälligkeitstermine nicht verwaltet.

Wenn ausgelöst, führt die CD-Pipeline die folgenden Schritte für die erneute Bereitstellung durch:

• Die Pipeline startet und versieht den aktuellen Commit (den Revert-Commit) mit der Lauf-ID der Pipeline.
• Die Pipeline liest den Inhalt des entsprechenden Umgebungszweigs aus diesem Tag.
• Die Pipeline berechnet das Bereitstellungsdelta zwischen dem aktuellen Commit und dem mit dem Tag <target-environment>_latest verbundenen Commit.
• Nach einer erfolgreichen Bereitstellung wird das <target-environment>_latest Tag in den neuen (zurückgesetzten) Commit verschoben.

Erstellen Sie einen Rollback-Promotion-Pull-Request

1. Identifizieren Sie die commit-id der Bereitstellungsversion im Inventar, zu der Sie zurückkehren möchten.
2. Setzen Sie den Zustand des Repositorys auf diesen Commit zurück.
3. Erstellen Sie einen Pull-Request, um den zurückgesetzten Zustand zu übernehmen.

Das folgende Beispiel veranschaulicht dieses Szenario anhand von git Befehlen.

1. Commits und Tags auflisten, um die Commit-ID des letzten bekannten guten Zustands zu finden (z. B. refs/tags/8)

   # /c/usr/devsecops/compliance-inventory (master)
   $ git show-ref --tags
   ...
   83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8 refs/tags/8
   ...
   1914a125e76aa97c497f4bd2c2f455b58cf079b8 refs/tags/prod_latest
   

2. Liste aller Commits zwischen dem aktuellen Zustand (refs/tags/prod_latest) und dem Zielzustand (refs/tags/8).

   # /c/usr/devsecops/compliance-inventory (master)
   $ git rev-list --no-merges HEAD...83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8
   67cc8babdff3e09c1f0e632f897798c1b5424f38
   6fab5ce3d60590cd858206424ecfd7d3a8c9ceb4
   ...
   

3. Den Inventarstatus auf den Ziel-Commit (refs/tags/8) zurücksetzen.

   # /c/usr/devsecops/compliance-inventory (master)
   $ git revert -n $(git rev-list --no-merges HEAD...83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8)
   

4. Den neuen Status festschreiben.

   # /c/usr/devsecops/compliance-inventory (master|REVERTING)
   $ git commit -m "revert master to 83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8"
   [master af82538] revert master to 83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8
   

5. Übertragen Sie das Update in den Master-Zweig.

   # /c/usr/devsecops/compliance-inventory (master)
   $ git push --set-upstream origin master
   ...
   To [https://us-south.git.cloud.ibm.com/jaunin.b/compliance-inventory.git](https://us-south.git.cloud.ibm.com/jaunin.b/compliance-inventory.git)
     67cc8ba..af82538  master -> master
   ...
   

Lösen Sie die Pipeline für kontinuierliche Bereitstellung aus

1. Erstellen Sie einen Pull-Request für die Rollback-Änderungen.

2. Überprüfen Sie den Pull Request und führen Sie ihn zusammen.

3. Lösen Sie den manuellen CD-Pipeline-Lauf in Ihrer CD-Toolchain aus.

Übersicht über Inline-Rollback

Dieser Modus rollt die aktuelle Bereitstellung im Rahmen desselben Pipeline-Laufs zurück. Dies ist erforderlich, wenn während der Bereitstellungs- oder Abnahmetestphase ein Fehler oder Ausfall auftritt, wodurch der Bereitstellungsversuch als fehlgeschlagen markiert wird.

Ein Inline-Rollback wird automatisch ausgeführt, wenn die rollback-enabled Umgebungseigenschaft auf 1 gesetzt ist und in der Bereitstellungs- oder Abnahmetestphase ein Fehler auftritt.

Wenn ein Rollback ausgelöst wird, führt die CD-Pipeline das Segment aus, das in Ihrer .pipeline-config.yaml``rollback Datei für definiert ist. Wenn ein rollback Segment in der Datei nicht definiert ist, wird eine Standardimplementierung ausgeführt und Sie werden aufgefordert, ein Rollback-Skript anzugeben.

Beispiel für ein Rollback-Skript in .pipeline-config.yaml:

rollback:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.74
  script: |
    #!/usr/bin/env bash
    if [[ "$PIPELINE_DEBUG" == 1 ]]; then
      trap env EXIT
      env
      set -x
    fi
    source $WORKSPACE/$PIPELINE_CONFIG_REPO_PATH/scripts/deploy_setup.sh
    source $WORKSPACE/$PIPELINE_CONFIG_REPO_PATH/scripts/rollback.sh

Während des Inline-Rollbacks festgelegte Eigenschaften

• rollback-status: Zeigt den Status des Rollback-Schritts an. Gültige Werte: [notRun, success, failure]
• rollback-exit-code Der Exit-Code des Rollback-Schritts. Dieser Wert ist leer, wenn das Rollback nicht ausgeführt wurde.
• default-rollback-executed: Setzen Sie auf, true wenn die Standardimplementierung (die zur Eingabe eines Skripts auffordert) ausgeführt wurde. Dieser Wert ist standardmäßig leer.
• pipeline-execution-status: Zeigt den Status des gesamten Pipeline-Durchlaufs an. Gültige Werte: [successful_deployment, failed_deployment_failed_rollback, failed_deployment_successful_rollback]