Gestione delle modifiche automatizzata

L'automazione della gestione delle modifiche è una parte importante dell'implementazione di riferimento della pipeline DevSecOps. Gli sviluppatori, gli approdi e i revisori possono monitorare gli aspetti di conformità delle distribuzioni. Ogni distribuzione deve seguire la politica di gestione delle modifiche di un'organizzazione.

Le pipeline raccolgono prove da ogni parte del ciclo di vita della build e della distribuzione. Ogni pezzo di evidenza correla a una specifica build e distribuzione dei manufatti. Quindi, per ogni manufatto distribuito, è possibile raccontare se la sua distribuzione o la distribuzione del test ha incidenti. Questa correlazione viene implementata attraverso il modello di inventario.

La connessione tra la prova, l'inventario e la gestione delle modifiche

La figura 1 mostra il flusso di dati e la connessione tra la prova, l'inventario e la gestione delle modifiche.

Collegamento tra evidenze, inventario e gestione del cambiamento
Collegamento tra evidenze, inventario e gestione del cambiamento

  1. L'IC esegue le risorse utente di build e lascia la prova di ciò che è accaduto durante la creazione di tali risorse utente.
  2. CI esegue la creazione di voci relative agli artefatti creati nell'inventario.
  3. Gli artefatti costruiti nell'Inventario sono promossi agli ambienti di distribuzione, come la staging o la pre - produzione.
  4. L'automazione di gestione delle modifiche utilizza i dati dell'inventario, l'armadietto delle prove e la promozione PR per creare le distribuzioni di richiesta di modifica. Change management automaton lascia anche prove di test di accettazione, ad esempio. Gli artefatti distribuiti e collaudati correttamente vengono ulteriormente promossi negli ambienti di produzione.

Ogni distribuzione ad ogni ambiente e regione deve deposita una richiesta di modifica sul Change Management System. L'automazione della gestione modifiche consente di creare queste richieste di modifiche in base a tutte le prove e le informazioni raccolte dalle pipeline.

Per ulteriori informazioni, consultare Automating change management.

Modifica ordine di comando di gestione

La sequenza dei passi di richiesta di modifica è la seguente:

Crea richiesta di modifica

Tutto ciò che cambia la baseline deve essere rintracciato utilizzando una richiesta di modifica. Le modifiche includono, ad esempio, gli aggiornamenti al livello di codice esistente, le modifiche alla configurazione e gli aggiornamenti dei nodi di lavoro. La raccolta dei dati di conformità peer review si basa sui dati accessibili nell'inventario, l'armadietto delle prove e il repository di problemi dell'incidente.

Infine, questo passo crea la richiesta di modifica che si basa sui campi Promotion PR e allega i dati di conformità disponibili. La prontezza di distribuzione è calcolata dallo stato di conformità raccolto, in base alle evidenze disponibili.

Richiesta di approvazione

Se lo stato di distribuzione della richiesta di richiesta di modifica non è pronto, questa fase richiede l'approvazione per la modifica.

Controllo per l'approvazione

Se ogni verifica di conformità (ad esempio, test di unità, attività CRA, protezione filiale, rileva i segreti) ha esito positivo, la richiesta di modifica viene approvata automaticamente e l'attività viene eseguita correttamente.

Se un controllo di conformità fallisce, lo stato di richiesta di modifica non viene approvato.

È possibile approvare la richiesta di modifica manualmente e aggiungere la modifica - richiesta - id alle proprietà dell'ambiente per utilizzare la richiesta di modifica già creata nella successiva esecuzione.

Un'altra soluzione è quella di utilizzare l'etichetta emergency nelle richieste di pull pull. Per ulteriori informazioni, consultare Aggiungi etichetta di emergenza.

Impostare su implement

Questo passo imposta lo stato della richiesta di modifica a implement a seconda dello stato success o failure del cambiamento.

Chiudi richiesta di modifica

I dettagli sulla distribuzione vengono caricati sull'attività di modifica di riepilogo della chiusura e la richiesta di modifica è chiusa. Nell'attività di richiesta di modifica chiusura, la close_category viene aggiunta con questi valori:

  • successful
  • successful with issues (se il riepilogo ha problemi)