Valutazione della preparazione allo schieramento

Prima di creare una richiesta di modifica, la pipeline calcola la prontezza di distribuzione e imposta il flag DEPLOYMENT_READY su true o false. Questo indicatore deriva dalle prove raccolte nelle fasi CI e CD. Se un qualsiasi controllo delle prove indica una deviazione o un controllo, una scansione o un test mancante o non riuscito relativo all'insieme di artefatti distribuiti, DEPLOYMENT_READY viene impostato su false.

La richiesta di modifica è preparata con i seguenti campi provenienti dall'ultimo PR di promozione unito al ramo di destinazione:

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

Creazione della richiesta di modifica

La richiesta di modifica preparata viene presentata in uno dei due stati iniziali, a seconda di DEPLOYMENT_READY:

Il sistema di gestione delle modifiche approva automaticamente le richieste di modifica quando l'implementazione non causa tempi di inattività (la durata dell'interruzione è pari a zero) e DEPLOYMENT_READY è true, e il rischio di implementazione è entro limiti accettabili.

Se le modifiche richiedono il fermo pianificato, è necessario creare la richiesta di modifica manualmente e inviarla per l'approvazione. Dopo essere stato approvato, è possibile avviare la distribuzione fornendo la richiesta di modifica ID. La pipeline controlla il suo stato di approvazione e poi esegue il deployment. Per ulteriori informazioni, consultare Approvando manualmente le richieste di modifica.

Allegati pre-impiego

Subito dopo la creazione della richiesta di modifica, la pipeline allega i seguenti artefatti al record CR:

• Distinta base dell'installazione: elenca tutti i componenti inclusi nell'installazione
• Riepilogo Delta- evidenza della postura di tutti i componenti che partecipano all'installazione
• File di configurazione dei controlli delle prove- da allegare solo se nella pipeline è configurato il gating basato sui controlli delle prove
• Profilo SCC- collegato solo se è configurata una configurazione di sicurezza e conformità

Cancello di approvazione

Se la richiesta di modifica è stata creata come Non approvata, viene posta in uno stato non approvato e inviata per la revisione umana. L'impiego non avviene fino a quando non viene concessa l'approvazione.

È possibile leggere l'ID della richiesta di modifica creata dai log della pipeline, attendere l'approvazione e quindi riavviare la distribuzione utilizzando lo stesso ID della richiesta di modifica. La pipeline controlla lo stato di approvazione e continua la distribuzione.

Test di distribuzione e accettazione

Con il CR in stato di implementazione, la pipeline viene eseguita:

• Distribuzione su CD: promuove il codice nell'ambiente di destinazione
• Test di accettazione: convalida il risultato dell'implementazione

Questi due sono stadi di esecuzione guidati dall'utente.

Chiusura del CR dopo lo spiegamento

Quando i test di deployment e di accettazione passano, la pipeline allega gli artefatti di chiusura e chiude la richiesta di modifica:

• Riepilogo di chiusura- un riepilogo delle evidenze per tutte le registrazioni d'inventario a livello di commit di destinazione.
• Merged SBOM- la distinta base del software dopo l'implementazione di tutti i componenti dell'inventario.

Il CR viene quindi chiuso con un close_category basato su DEPLOYMENT_READY al momento della chiusura:

Tipi di cambiamento

Change Request Management supporta due tipi di modifica: emergency o regolare.

Se la modifica corrente è una modifica di emergenza, aggiungere l'etichetta emergency alla richiesta pull pull.

Non c'è flusso di emergenza sul lato della condotta CI. Tuttavia, impostando la proprietà della pipeline CI/trigger skip-inventory-update-on-failure su un valore vuoto o su 0 si può aggiornare il repository dell'inventario anche se i problemi vengono rilevati nell'esecuzione della pipeline CI. Con questo inventario aggiornato, è possibile attivare un cambio di emergenza.

Scegliere un percorso di recupero

Percorso 1: rollback completo utilizzando l'ascoltatore di rollback dedicato

Se esiste una configurazione last-known-good, cioè uno stato precedentemente implementato e confermato come stabile, il percorso più rapido per il ripristino del servizio è un rollback completo. Si utilizza un listener di rollback dedicato, creato appositamente per questo scenario e che non richiede una nuova compilazione o promozione.

Per le istruzioni passo-passo e i parametri da configurare, vedere Rollback completo usando l'ascoltatore di rollback dedicato.

Percorso 2: Fix-forward come modifica d'emergenza

Se non esiste un obiettivo di rollback praticabile o se l'indagine ha già prodotto una patch, la correzione può essere distribuita come modifica di emergenza. Questo percorso cortocircuita la logica standard di selezione delle prove: la pipeline consente l'implementazione immediata della modifica, mentre la richiesta di modifica è soggetta a revisione e approvazione retroattiva dopo la risoluzione dell'incidente.

Utilizzare questo percorso significa accettare che il codice distribuito in produzione possa ancora contenere vulnerabilità non risolte o lacune aperte. Il ripristino del servizio è considerato la priorità più alta e le questioni di conformità in sospeso devono essere affrontate dopo la chiusura dell'incidente.

Questi due percorsi non si escludono a vicenda. In pratica, i team possono avviare prima un rollback completo per ripristinare immediatamente il servizio, e poi seguire con un fix-forward una volta che la patch è pronta e convalidata. La sequenza è lasciata al giudizio dell'operatore in base alla situazione.

Procedura Fix-forward

Per distribuire una correzione come modifica di emergenza durante un CIE, procedere come segue:

1. Ricostruire il componente interessato. Eseguire la pipeline CI per creare una nuova versione dell'artefatto contenente la correzione. Se i controlli delle evidenze dell'IC non riescono a causa delle condizioni dell'incidente, impostare la proprietà della pipeline o del trigger skip-inventory-update-on-failure su un valore vuoto o su 0 per consentire l'aggiornamento dell'inventario nonostante i fallimenti, in modo che la modifica di emergenza possa procedere.

2. Promuovere la correzione attraverso gli ambienti. Creare richieste di pull di promozione partendo dall'ambiente più basso e promuovendo verso l'alto la produzione. Se il tempo lo consente, verificare la correzione in ogni fase prima di promuovere ulteriormente. Se la situazione è critica, passare direttamente alla produzione e riconciliare gli ambienti inferiori dopo il ripristino del servizio.

3. Applicare l'etichetta di emergenza. Nella richiesta di pull di promozione mirata alla produzione, aggiungere l'etichetta emergency. Questo segnala alla pipeline che il gating delle prove standard deve essere bypassato e che la modifica deve essere trattata come un'implementazione di emergenza.

4. Distribuire in produzione. Eseguire la pipeline del CD. La pipeline rileva l'etichetta di emergenza, salta l'attesa dell'approvazione e procede immediatamente all'implementazione e ai test di accettazione. La richiesta di modifica viene creata e chiusa con close_category = successful with issues, a testimonianza del fatto che la modifica è stata distribuita in condizioni di emergenza.

5. Riconciliare gli ambienti più bassi. Dopo aver risolto l'incidente di produzione, distribuire lo stesso artefatto di correzione di emergenza in ambienti inferiori, come staging, pre-produzione e così via, in modo che tutti gli ambienti siano in uno stato coerente con la produzione. Se gli ambienti inferiori sono stati verificati prima di passare alla produzione, confermate che la stessa versione dell'artefatto è presente in tutti i livelli.

Obblighi post-CIE

Un intervento di emergenza comporta obblighi di conformità che devono essere affrontati dopo la chiusura dell'incidente:

• La richiesta di modifica deve essere rivista e approvata retroattivamente dagli approvatori appropriati.
• Tutte le lacune di evidenza accettate durante l'emergenza - vulnerabilità non risolte, scansioni incomplete o controlli falliti - devono essere corrette e la pipeline deve essere rieseguita in condizioni standard.
• È necessario condurre e documentare un'analisi delle cause principali (RCA).

Il record della richiesta di modifica, compresi il riepilogo Delta, il riepilogo di chiusura e l'SBOM unito allegato dalla pipeline, serve come traccia di controllo principale per la revisione post-CIE.

Richiamo del flusso di emergenza

Il flusso di emergenza è avviato dall'utente:

1. L'utente esegue la pipeline con l'etichetta emergency applicata alla richiesta di promozione.
2. La conduttura rileva la designazione di emergenza e l'implementazione e i test di accettazione procedono immediatamente senza attendere l'approvazione standard.
3. Il CR viene chiuso con le note di chiusura come successful with issues.

Se la modifica in corso è una modifica di emergenza, aggiungere l'etichetta emergency alla richiesta di pull di promozione prima di eseguire la pipeline.

Impiego post-emergenza

Una volta che il flusso di emergenza ha completato la distribuzione e i test, si ricongiunge al flusso standard nella fase successiva alla distribuzione:

• Il riepilogo di chiusura e l'SBOM unificato sono allegati alla CR.
• Il CR viene chiuso seguendo la stessa logica DEPLOYMENT_READY- basata su close_category del flusso standard.

Se il tipo di CR è emergency, la richiesta di modifica deve essere rivista e approvata retroattivamente dopo la distribuzione.

Condizione di attivazione

Il flusso inline-rollback viene inserito quando i test di distribuzione o di accettazione non vengono superati. La pipeline valuta quindi se l'inline-rollback è abilitato:

• Inline-Rollback non abilitato: Il CR viene lasciato aperto con close_category = unsuccessful e la pipeline esce. Non viene tentato il recupero automatico.
• Rollback abilitato: Lo script di rollback viene eseguito per ripristinare l'ambiente di destinazione e gli artefatti del rollback vengono raccolti e allegati al CR.

Esecuzione del rollback in linea

Quando il rollback in linea è abilitato, la pipeline:

1. Esegue lo script inline-rollback se il deployment o il test di accettazione non è riuscito nella pipeline CD.
2. Raccoglie i seguenti artefatti:
   • Registri di rollback: output dell'esecuzione dello script di rollback
   • Riepilogo di chiusura- riflette il risultato del rollback
   • SBOM fuso- distinta base del software post-rollback
3. Allega tutti e tre gli artefatti al record CR aperto.

Chiusura del CR dopo il rollback

Dopo l'inline-rollback e l'allegato del manufatto, il CR viene lasciato aperto con close_category = unsuccessful. Questo segnala alla gestione delle modifiche che l'implementazione è stata tentata, non è riuscita ed è stata automaticamente annullata.

Un CR con close_category = unsuccessful è il risultato atteso e corretto quando un'implementazione viene invertita, non un'indicazione di un fallimento del processo. I team operativi devono utilizzare i registri di rollback allegati per indagare sulla causa principale.

Esecuzione della pipeline con una richiesta di modifica pre-approvata

È possibile utilizzare una richiesta di modifica (CR) pre-approvata per la distribuzione. Sono possibili due scenari:

Quando la pipeline CD riconosce il CR come creato da un'esecuzione precedente della pipeline CD, esegue un percorso rapido per l'installazione:

• Riutilizzo del delta precalcolato e del riepilogo delle prove dalla prova CR.
• Saltare le fasi di revisione tra pari e verifica della firma.
• Implementazione del delta precalcolato.

Quando la pipeline CD non riesce a determinare se il CR è stato creato da un'esecuzione precedente della pipeline CD o se il CR fornito non corrisponde all'obiettivo di distribuzione dell'esecuzione corrente:

• Non riutilizza alcun delta precalcolato o sintesi delle prove.
• Non salta la revisione tra pari o la verifica della firma del manufatto.
• Ricalcola il delta e il riepilogo da zero.
• Non crea un nuovo CR, poiché ne è già stato fornito uno.

Esecuzione di nuovo della pipeline contro un'installazione fallita

Se non si desidera utilizzare la gestione dei cambiamenti automatizzati, è possibile fornire una richiesta di modifica creata e approvata in precedenza. Rieseguire le distribuzioni non riuscite nei seguenti scenari:

• L'ultima richiesta di modifica creata automaticamente non è pronta per la distribuzione e non è stata approvata automaticamente. L'utente ha ricevuto l'approvazione e deve riavviare l'installazione utilizzando la stessa richiesta di modifica.
• La distribuzione richiede tempi di fermo. Avete creato la richiesta di modifica, è stata approvata e avete seguito la politica di gestione delle modifiche della vostra organizzazione.
• Nessun codice o configurazione modificato. Si è creata la richiesta di modifica, si è spiegato cosa è cambiato, si è ricevuta l'approvazione e si è avviata la distribuzione utilizzando la richiesta di modifica approvata.

La richiesta di modifica (CR) rimane aperta dopo il completamento della pipeline CD.

È possibile avviare la pipeline di distribuzione continua di riferimento DevSecOps utilizzando una richiesta di modifica pre-approvata e inserendo l'ID della richiesta di modifica nella proprietà change-request-id.

Se la proprietà change-request-id è impostata, la pipeline salta la raccolta dei dati per la richiesta di modifica e passa a verificare lo stato di approvazione. Se change-request-id è impostato di default su notAvailable, una richiesta di modifica viene creata automaticamente dalla pipeline.