Comportamento predefinito (senza reinstallazione forzata)

Quando non force-redeploy è impostato o è impostato su false, la pipeline viene distribuita solo quando vengono rilevate nuove modifiche nel repository dell'inventario per l'ambiente di destinazione.

1. La pipeline CD avvia e contrassegna il commit corrente con l'ID di esecuzione della pipeline.

2. La pipeline legge il contenuto del ramo dell'ambiente corrispondente da quel tag.

3. La pipeline calcola il delta di distribuzione tra il commit corrente e il commit associato al <target-environment>_latest tag.

4. La pipeline valuta il delta:

   • Se il delta è vuoto, la pipeline si interrompe e non viene eseguita alcuna distribuzione.
   • Se il delta contiene modifiche, la pipeline continua.

5. La pipeline distribuisce le modifiche identificate nel delta.

6. Dopo una distribuzione riuscita, la pipeline allega il <target-environment>_latest tag al nuovo commit.

Comportamento forzato (con ridistribuzione della forza)

Quando force-redeploy è impostato su true, la pipeline ignora la convalida delta e ridistribuisce l'inventario completo, indipendentemente dalle modifiche rilevate. Questo approccio garantisce che lo stato completo dell'applicazione venga riapplicato alla destinazione di distribuzione.

1. La pipeline CD avvia e contrassegna il commit corrente con l'ID di esecuzione della pipeline.
2. La pipeline legge il contenuto del ramo dell'ambiente corrispondente da quel tag.
3. La pipeline calcola il delta di distribuzione, che in questo scenario è tipicamente vuoto.
4. L'impostazione force-redeploy=true fa sì che la pipeline salti il controllo delta e proceda.
5. La pipeline ridistribuisce l'intero stato dell'applicazione dal ramo.
6. Dopo una ridistribuzione riuscita, la pipeline allega il <target-environment>_latest tag al commit appena distribuito.

Panoramica della pipeline di rollback

Questa pipeline consente di ripristinare una configurazione precedente nota come corretta, selezionando uno specifico ID richiesta ServiceNow di modifica (ad esempio, CHG-12345).

Questo ID richiesta di modifica funge da segnalibro univoco per una distribuzione riuscita ed è un input obbligatorio per la pipeline di rollback.

È possibile trovare l'ID della richiesta di modifica per una distribuzione precedente in due modi:

• ServiceNow: individuare la richiesta di modifica relativa alla distribuzione che si desidera ripristinare.
• Repository dell'inventario: poiché lo stato dell'inventario è gestito nel controllo del codice sorgente, ogni distribuzione è identificata in modo univoco da un commit. È possibile trovare il commit a cui si desidera tornare e identificare il CHG-*** tag associato a quel commit.

La pipeline di rollback comprende le seguenti fasi:

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

Il processo della pipeline utilizza le informazioni della proprietà rollback-change-request-id environment per creare una nuova richiesta di modifica.

Per mantenere la conformità, la pipeline riapre le questioni legate alla precedente implementazione. Queste richieste sono allegate alla nuova richiesta di modifica e le loro date di scadenza originali rimangono invariate. Un rollback riuscito sposta il _latest tag nell'inventario al commit precedente.

Creare una pipeline di rollback

Utilizza il comando cd-rollback-listener per eseguire un rollback all'ultima versione funzionante conosciuta.

1. Vai alla tua pipeline CD.
2. Aggiungi un trigger manuale o duplica il trigger CD manuale.
3. Modifica il trigger e imposta il listener su cd-rollback-listener.
4. Seleziona Salva.
5. Creare un trigger separato per ogni combinazione richiesta di regione e ambiente di destinazione.

Attivare una pipeline di rollback

L'esecuzione di una pipeline di rollback utilizza le seguenti proprietà dell'ambiente:

La pipeline termina a meno che non siano soddisfatti i seguenti criteri:

• rollback-change-request-id deve essere l'ID di una distribuzione completata per la stessa regione e lo stesso ambiente di destinazione.
• Il deployment associato a non rollback-change-request-id deve essere più vecchio del numero di deployment specificato da rollback-limit.

La proprietà PIPELINE_NAME dell'ambiente Tekton determina se un'esecuzione è una distribuzione o un rollback.

• cd-rollback-pipeline: Valore predefinito per un rollback.
• cd-pipeline: Valore predefinito per una distribuzione.

È possibile utilizzare questa proprietà per personalizzare la logica di ramificazione.

Panoramica del rollback utilizzando GitOps

Utilizza la pipeline di distribuzione continua per distribuire una versione precedente dell'inventario nell'ambiente di destinazione utilizzando Git operazioni che ripristinano le modifiche a uno specifico commit-id.

Poiché stai ripristinando i commit direttamente nel repository dell'inventario invece di attivare la pipeline di rollback con un ID richiesta ServiceNow di modifica, questo processo non riapre automaticamente i precedenti problemi di conformità né gestisce le loro date di scadenza.

Quando viene attivata, la pipeline CD completa i seguenti passaggi per la ridistribuzione:

• La pipeline avvia e contrassegna il commit corrente (il commit di ripristino) con l'ID di esecuzione della pipeline.
• La pipeline legge il contenuto del ramo dell'ambiente corrispondente da quel tag.
• La pipeline calcola il delta di distribuzione tra il commit corrente e il commit associato al <target-environment>_latest tag.
• Dopo una distribuzione riuscita, il <target-environment>_latest tag viene spostato al nuovo commit (ripristinato).

Crea una richiesta pull per la promozione Rollback

1. Identificare la versione di commit-id distribuzione nell'inventario a cui si desidera eseguire il rollback.
2. Ripristina lo stato del repository a quel commit.
3. Crea una richiesta pull per promuovere lo stato ripristinato.

L'esempio seguente illustra questo scenario utilizzando git i comandi.

1. Elenca i commit e i tag per trovare l'ID del commit dell'ultimo stato corretto noto (ad esempio, refs/tags/8)

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

2. Elenca tutti i commit tra lo stato attuale (refs/tags/prod_latest) e lo stato target (refs/tags/8).

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

3. Ripristina lo stato dell'inventario al commit di destinazione (refs/tags/8).

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

4. Conferma il nuovo stato.

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

5. Invia l'aggiornamento al ramo master.

   # /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
   ...
   

Attiva la pipeline di distribuzione continua

1. Crea una richiesta pull per le modifiche alla promozione del rollback.

2. Esamina e unisci la richiesta pull.

3. Avvia l'esecuzione manuale della pipeline CD nella tua catena di strumenti CD.

Panoramica del rollback in linea

Questa modalità ripristina la distribuzione corrente nel contesto della stessa esecuzione della pipeline. È necessario quando si verifica un errore o un guasto durante la fase di implementazione o di test di accettazione, causando il fallimento del tentativo di implementazione.

Il rollback in linea viene eseguito automaticamente se la rollback-enabled proprietà dell'ambiente è impostata su 1 e si verifica un errore nella fase di test di distribuzione o accettazione.

Se viene attivato un rollback, la pipeline CD esegue il segmento definito per rollback nel .pipeline-config.yaml file. Se un rollback segmento non è definito nel file, viene eseguita un'implementazione predefinita e viene richiesto di fornire uno script di rollback.

Esempio di script di rollback 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

Proprietà impostate durante il rollback in linea

• rollback-status: Indica lo stato della fase di rollback. I valori possibili sono: [notRun, success, failure]
• rollback-exit-code: Il codice di uscita della fase di rollback. Questo valore è vuoto se il rollback non è stato eseguito.
• default-rollback-executed: Impostare su true se è stata eseguita l'implementazione predefinita (che richiede uno script). Questo valore è vuoto per impostazione predefinita.
• pipeline-execution-status: Indica lo stato dell'esecuzione complessiva della pipeline. I valori possibili sono: [successful_deployment, failed_deployment_failed_rollback, failed_deployment_successful_rollback]