Separazione delle funzioni durante le promozioni

• Promozioni ottenute principalmente attraverso il flusso di lavoro delle Pull Request

  • → Creare un PR di promozione (ad esempio, dal ramo dell'ambiente di origine a quello di destinazione)
  • → Esaminare/modificare la PR (compresa la verifica dello stato di convalida della PR)
  • → Unire la pull request nel ramo dell'ambiente di destinazione
  • → Esegui la pipeline di distribuzione del CD (al commit, a tempo o con attivazione manuale)
  • → Ripetere l'operazione per il ramo dell'ambiente successivo
  • → È possibile avere un numero arbitrario di rami di ambiente

• Ruoli

  • Sviluppatore: esegue il commit del codice, determinando l'aggiornamento dell'inventario principale (non di produzione) da parte della pipeline di CI
  • Responsabile delle operazioni di promozione / Release Manager: avvia la pipeline di promozione (main→staging e/o staging→prod), creando PR con controllo dello stato per il gating (applicato tramite gli ACL della toolchain e le protezioni dei rami di inventario)
  • Operazioni di produzione / Responsabile dell'approvazione: verificare e integrare il PR di promozione nel ramo di produzione. Eseguire le pipeline di produzione. (garantito dalla protezione del ramo "inventory")

• Sfruttare i carichi di lavoro di catene di strumenti CD distinte per l'ambiente di staging e quello di produzione (Ops distinte)

• Ciò significa che uno sviluppatore può preparare una modifica, ma non può implementarla unilateralmente in produzione se la protezione del ramo richiede l'approvazione di un altro utente.

• Il PR di promozione diventa il documento ufficiale di approvazione della modifica, mentre la cronologia delle fusioni fornisce prove verificabili su chi abbia approvato la promozione in produzione e quando.

Fasi della pipeline della promozione

1. Ottenere gli input per la promozione e la richiesta di pull / unione della promozione.
2. Promuovere le voci di inventario dall'ambiente di origine all'ambiente di destinazione.
3. Creare la richiesta di estrazione / unione della promozione. Modificare la richiesta di estrazione / unione per indicare quali modifiche eseguire. Controlla i campi facoltativi e obbligatori.
4. Facoltativo. Impostare gli stati delle prove e aggiungere il riepilogo delle prove aggregate alla richiesta di pull / unione della promozione.
5. Unire la richiesta di pull / merge.
6. Invia una notifica Slack se la funzione è attivata.

Fasi e attività

La tabella seguente elenca le attività eseguite in una pipeline di promozione. Inoltre, la tabella offre anche una panoramica di ciascuna di queste fasi:

• Attività o fase: si riferisce al nome della fase così come definito nel file di configurazione .pipeline-config.yaml.

• Breve descrizione: Questa sezione fornisce una spiegazione sintetica delle azioni eseguite durante lo svolgimento della fase.

• Personalizzazione consentita : indica se gli utenti hanno la possibilità di modificare o sostituire il comportamento predefinito della fase inserendo uno script personalizzato nel file .pipeline-config.yaml .

• Implementazione di riferimento predefinita: indica se le pipeline di DevSecOps dispongono di un'implementazione predefinita o di default per la fase. In particolare, per alcune fasi come unit-tests o setup, la pipeline DevSecOps non offre alcuna implementazione predefinita. Gli utenti devono invece fornire script personalizzati o codice su misura per le esigenze della propria applicazione.

• Raccolta delle prove: indica se la fase prevede la raccolta delle prove standard. Quando una pipeline “ DevSecOps ” fornisce un’implementazione di riferimento per una fase, la raccolta delle prove viene eseguita immediatamente, senza necessità di configurazioni aggiuntive. Tuttavia, se l'utente decide di modificare o sostituire queste fasi predefinite, deve assicurarsi che le proprie implementazioni personalizzate prevedano un'adeguata raccolta delle prove. La stessa responsabilità ricade sugli utenti nelle fasi in cui la pipeline “ DevSecOps ” non fornisce un’implementazione predefinita, rendendo necessario che siano loro a procedere alla raccolta delle prove. La colonna indica l'entità ( Utente/Pipeline ) responsabile dell'esecuzione della raccolta delle prove.

• Salto consentito (applicabile alla versione >= v10 ): indica se gli utenti possono scegliere di non eseguire questa fase impostando la proprietà "skip" su "true" nel file .pipeline-config.yaml. Si raccomanda tuttavia di prestare attenzione nell'utilizzo di questa funzione, soprattutto nelle fasi dedicate alla raccolta delle prove. Saltare tali fasi potrebbe comportare la perdita di prove essenziali per la compilazione.

Per ulteriori informazioni su come personalizzare le fasi utilizzando il file .pipeline-config.yaml , consultare le sezioni “Script personalizzati ” e “Elenchi dei parametri della pipeline ”.

Esecuzione della pipeline di promozione

Utilizzare il trigger della promozione manuale per eseguire la pipeline della promozione. Se il ramo di origine (master) è più avanti del ramo di destinazione (prod), la pipeline crea una richiesta di pull / unione di promozione che è possibile rivedere e modificare. Se il ramo di origine è dietro la destinazione, la pipeline di promozione ha esito negativo con il messaggio All changes have already been promoted.

Per modificare i valori predefiniti della richiesta di pull / unione della promozione o per eseguire la promozione da un'origine alternativa a una destinazione, gli utenti possono modificare gli input dalla IU delle variabili di ambiente della pipeline.

Prima di eseguire la pipeline di distribuzione continua, assicurarsi che la richiesta di pull / unione della promozione sia unita. Puoi trovare la richiesta URL pull/merge nei log della pipeline.

Per ulteriori informazioni sul processo di inventario e promozione, vedere Promozione inventario.

Promozione parziale degli articoli di inventario

Il metodo di promozione parziale consente alla pipeline di promozione di promuovere un sottoinsieme selezionato di inventario disponibile.

In questo contesto, una voce dell'inventario corrisponderebbe a un singolo file (del tipo "inventario") presente nel repository dell'inventario; tale voce corrisponderebbe a un nome file univoco nel filesystem locale

Utilizzando i parametri inventory-include E inventory-exclude abilita il metodo di promozione parziale.

Quando si usa inventory-include, i modelli/nomi file forniti nella proprietà dell'ambiente si risolvono nelle rispettive voci e vengono promossi dalla pipeline. Allo stesso modo, le voci fornite in inventory-exclude essere escluso dalla promozione.

Il formato utilizza il modello glob (supporta anche percorsi completi), in modo simile a quanto seguito nella pipeline CC. Per ulteriori informazioni sui modelli glob, consultare glob Manuale.

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

Richieste di pull / unione promozione

Le informazioni dal corpo della richiesta di pull / unione della promozione vengono utilizzate per creare la richiesta di modifica. I file modificati dalla richiesta di pull / unione della promozione rappresentano le voci, ad esempio le immagini, distribuite dalla pipeline di distribuzione continua. Se le modifiche sono state apportate a causa di un'emergenza, la richiesta di estrazione / unione della promozione è contrassegnata con un'etichetta di emergenza. Anche la richiesta di modifica creata dalla pipeline di distribuzione continua è contrassegnata come emergency.

La prova raccolta nella pipeline di integrazione continua viene riepilogata e allegata alla richiesta di modifica nella pipeline di distribuzione continua.

Pipeline di convalida promozione

Una volta aperta una RdA della promozione, è possibile facoltativamente eseguire l'aggregazione della prova e la creazione di riepilogo nella pipeline di convalida della promozione e impostare gli stati della prova sulla richiesta di pull / unione della promozione (RdA). La RdA può essere creata dalla pipeline di promozione o manualmente nel repository di inventario.

La pipeline abilita la convalida anticipata della PR della promozione prima che la PR venga unita al ramo di destinazione (ambiente). In base allo stato della RdA, gli utenti possono procedere con la promozione (quando tutti gli stati della prova sono verdi) oppure scegliere di risolvere il problema nella pipeline di integrazione continua (quando lo stato della prova è rosso).

Inoltre, la pipeline di convalida aggiunge anche il riepilogo aggregato delle prove relative a una o più applicazioni presenti nell'inventario alla richiesta di promozione pull/merge sotto forma di commento, in un formato tabellare di facile consultazione (come mostrato nella Figura 3). La tabella fornisce link utili, come link a pipeline, repository di app e problemi creati per ciascuna delle applicazioni.

Per impostazione predefinita, ogni riga nella tabella Dettagliato stato delle prove corrisponde a un contesto applicativo fornito da un repository di origine utilizzato per creare gli artefatti a cui si fa riferimento nelle voci dell'inventario. Questo raggruppamento predefinito dell'applicazione può essere personalizzato in base a un valore di raggruppamento ottenuto applicando il filtro JSON (definito nella proprietà application-group-by-filter) su ciascun file di voce dell'inventario.

Mentre la convalida è in corso, l'unione della richiesta di estrazione / unione della promozione è bloccata. Una volta completata la pipeline di convalida, lo stato della prova viene impostato sulla richiesta di pull / unione. Facendo clic su ciascuna voce nello stato, l'utente viene condotto allo stage specifico nell'esecuzione della pipeline IC corrispondente.

Fasi e attività

La tabella seguente elenca le attività eseguite in una pipeline di convalida della promozione. Inoltre, la tabella offre anche una panoramica di ciascuna di queste fasi:

• Attività o fase: si riferisce al nome della fase così come definito nel file di configurazione .pipeline-config.yaml.

• Breve descrizione: Questa sezione fornisce una spiegazione sintetica delle azioni eseguite durante lo svolgimento della fase.

• Personalizzazione consentita : indica se gli utenti hanno la possibilità di modificare o sostituire il comportamento predefinito della fase inserendo uno script personalizzato nel file .pipeline-config.yaml .

• Implementazione di riferimento predefinita: indica se le pipeline di DevSecOps dispongono di un'implementazione predefinita o di default per la fase. In particolare, per alcune fasi come unit-tests o setup, la pipeline DevSecOps non offre alcuna implementazione predefinita. Gli utenti devono invece fornire script personalizzati o codice su misura per le esigenze della propria applicazione.

• Raccolta delle prove: indica se la fase prevede la raccolta delle prove standard. Quando una pipeline “ DevSecOps ” fornisce un’implementazione di riferimento per una fase, la raccolta delle prove viene eseguita immediatamente, senza necessità di configurazioni aggiuntive. Tuttavia, se l'utente decide di modificare o sostituire queste fasi predefinite, deve assicurarsi che le proprie implementazioni personalizzate prevedano un'adeguata raccolta delle prove. La stessa responsabilità ricade sugli utenti nelle fasi in cui la pipeline “ DevSecOps ” non fornisce un’implementazione predefinita, rendendo necessario che siano loro a procedere alla raccolta delle prove. La colonna indica l'entità ( Utente/Pipeline ) responsabile dell'esecuzione della raccolta delle prove.

• Salto consentito (applicabile alla versione >= v10 ): indica se gli utenti possono scegliere di non eseguire questa fase impostando la proprietà "skip" su "true" nel file .pipeline-config.yaml. Si raccomanda tuttavia di prestare attenzione nell'utilizzo di questa funzione, soprattutto nelle fasi dedicate alla raccolta delle prove. Saltare tali fasi potrebbe comportare la perdita di prove essenziali per la compilazione.

Per ulteriori informazioni su come personalizzare le fasi utilizzando il file .pipeline-config.yaml , consultare le sezioni “Script personalizzati ” e “Elenchi dei parametri della pipeline ”.

Come accettare la convalida della promozione?

Deprecata L'opzione opt-in-promotion-validation che veniva usata per avviare automaticamente la pipeline di validazione delle promozioni su una richiesta di pull è deprecated a favore dell'opzione Git Promotion Validation trigger. Se hai questa proprietà nelle impostazioni di ambiente, visualizzerai l'avviso di obsolescenza nei log della pipeline e nella notifica Slack.

Come abilitare la convalida della promozione?

Per tutte le nuove catene di strumenti CD, viene creato automaticamente un trigger denominato “ Git ” (Convalida promozione) e impostato come abilitato.

Per abilitare il trigger Git Promotion Validation su una pipeline esistente, puoi utilizzare la seguente procedura.

1. Vai alla pagina Trigger della pipeline CD a cui vuoi aggiungerla.
2. Seleziona Aggiungi> Git Repository per aggiungere un nuovo trigger.
3. Immettere le seguenti informazioni richieste per il trigger:
   • Fornire un nome trigger. Ad esempio: Git Promotion Validation Trigger.
   • Specificare promotion-validation-listener or promotion-validation-listener-gitlab come EventListener.
   • Selezionare il repository di inventario corrispondente per la pipeline per il campo Repository.
   • Selezionare il nome dell'ambiente di destinazione per il ramo.
   • Selezionare la casella per il campo Quando una richiesta di pull viene aperta o aggiornata.
4. Fai clic su Aggiungi.
5. Impostare il trigger su On.

Input

Risultati ed effetti

• Notifica Slack
• Richiesta di estrazione / unione promozione

È necessario modificare la richiesta di estrazione / unione se non sono stati forniti i parametri facoltativi.

Quando viene eseguita la convalida della RdA della promozione (facoltativa), lo stato della prova viene impostato sulla richiesta di estrazione / unione.

Il riepilogo delle prove aggregate (che possono provenire da più applicazioni nell'inventario) viene visualizzato in formato tabella come commento nella RdA.

Passo successivo

Una volta terminata correttamente la pipeline di promozione, è possibile procedere con la pipeline CD.