Gestione del peer - review Check in CI/CD Toolchain

Questa documentazione fornisce istruzioni per abilitare e disabilitare il controllo di revisione peer in CI (Continuous Integration) e facoltativo nelle toolchain CD ( Continuous Delivery ).

Punti importanti

È necessario condurre revisioni peer solo sul ramo protetto (di base), che è il punto in cui viene aggiornato l'inventario. Se si sta eseguendo una pipeline CI su un ramo della funzione, impostare la variabile di ambiente peer-review-compliance su 0 per tale trigger specifico per impedire il controllo della revisione peer sul ramo della funzione.

L'adesione alla conformità della revisione peer è subordinata al completamento di un'esecuzione della pipeline CI (Continuous Integration) e alla successiva immissione nell'inventario. Di conseguenza, l'esecuzione iniziale della pipeline CI ignorerà il controllo di conformità della revisione peer.

Per garantire la conformità con gli standard di revisione peer, si presume che gli aggiornamenti dell'inventario nella fase ci-finish si verifichino sul ramo master. Tuttavia, se gli aggiornamenti dell'inventario vengono effettuati su un ramo diverso da quello principale, è possibile impostare la variabile di ambiente inventory-repo-branch per indicare il ramo in cui si stanno effettuando gli aggiornamenti dell'inventario.

Si prevede che nella pipeline di distribuzione continua (CD), tutti gli aggiornamenti dell'inventario apportati al repository dell'inventario vengano promossi al ramo di destinazione in fase di distribuzione, assicurando che non vengano persi commit. Per impostazione predefinita, durante la distribuzione, il repository dell'inventario viene controllato nel ramo di destinazione. Tuttavia, se nel ramo di destinazione della promozione dell'inventario mancano alcuni commit tra il ramo di base e quello di destinazione, è possibile impostare la variabile d'ambiente inventory-repo-branch per specificare il ramo di base in cui si trovano tutti i commit dell'inventario.

Per impostazione predefinita, la pipeline CI (Continuous Integration) eseguirà automaticamente un commit nel repository di inventario al termine dell'esecuzione, utilizzando il nome applicazione come voce di inventario. Tuttavia, se intendi modificare la voce di inventario durante la fase di rilascio, ti consigliamo di incorporare una proprietà di ambiente denominata inventory-entry-name nella tua toolchain. Questa proprietà deve contenere il nome inventario modificato per il processo di revisione peer.

Se avete un'automazione che spinge i commit direttamente al ramo protetto e volete evitare problemi con i controlli di conformità della revisione paritaria, assicuratevi che il messaggio di commit includa ##AUTOMATED_COMMIT##.

L'implementazione di riferimento rileva istanze di codice che non sono sottoposte a revisione peer, raccoglie prove e crea problemi di incidente per tenere traccia di questi elementi.

Prima di poter unire il codice nel ramo principale (protetto), il codice deve essere revisionato da una persona che non ha caricato il codice modificato.

Il repository del codice (repository) deve avere almeno due membri: un membro che dispone dei privilegi di amministratore e un altro membro che dispone dei privilegi di scrittura. Se il codice viene unito a un repository senza una revisione, l'azione deve essere visibile nella traccia di controllo del repository di codici. Eseguire periodicamente la scansione della traccia di controllo per identificare e analizzare queste situazioni eccezionali.

La pipeline raccoglie i dati di conformità della revisione peer durante le build e le installazioni per creare la traccia di controllo dalle unioni di richieste di pull / unione del codice alle richieste di modifica.

In questo diagramma, PR1, PR2 sono le richieste di pull / unione approvate prima dell'integrazione. In modo simile, per PR4, PR5e PR7. Tuttavia, PR3 e PR6, evidenziate in rosso, vengono unite senza approvazione, che è una violazione di conformità della revisione peer. Questa viene catturata come prova.

Per default, l'applicazione di esempio nella toolchain IC tenta di impostare il numero minimo di revisori su 1. Se si desidera cambiare il numero di revisori, impostare la proprietà di ambiente peer_review_approvers come richiesto. Per ulteriori informazioni sull'impostazione del numero minimo di revisori richiesti per una richiesta di pull / merge, consulta le seguenti risorse GitHub e GitLab:

• GitHub: Richiedere più revisori per le richieste di pull
• GitLab: Regole di approvazione delle richieste di fusione

Dati raccolti in esecuzioni di build di integrazione continua

Questa raccolta dati contiene un elenco di tutti i commit per le richieste di pull / unione che sono state unite nei repository dell'applicazione dall'ultima build.

I dati della richiesta di pull vengono raccolti direttamente dai repository dell'applicazione. Vengono raccolti i dati per ogni richiesta di pull / unione relativa ai commit tra il commit del repository che ha attivato la build precedente e il commit attualmente disponibile.

I commit che non contengono una richiesta di pull / merge creano un problema di conformità nelle seguenti release della pipeline. Non è possibile eseguire il commit direttamente al ramo principale.

Un incidente di conformità generalmente contiene le seguenti informazioni:

• Elenco di URL di richieste di pull / unione per il commit associato.
• Repository dell'applicazione.
• ID commit.
• Numero di approvazioni richiesto.

I dati raccolti vengono salvati come una risorsa utente prova, che viene caricata nel blocco di prove e a cui si fa riferimento nella prova stessa. Il risultato della prova finale è determinato dalle richieste di pull / unione approvate. Non approvato, ma le richieste di pull / unione unite hanno esito negativo per questo tipo di prova.

I dati raccolti nelle esecuzioni di distribuzione continua

Questa raccolta di dati contiene un elenco di tutte le richieste di pull / unione che sono state unite nei repository dell'app dall'ultima distribuzione.

I dati della richiesta di pull vengono raccolti dal locker delle prove e dal repository del problema dell'incidente.

• L'inventario raccoglie i dati da tutte le build sulle risorse correlate dall'ultima distribuzione.
• Il locker delle prove raccoglie i dati di revisione del peer memorizzati dalle build.
• Il repository di problemi dell'incidente raccoglie informazioni sugli incidenti di richiesta di pull / unione aperti.

Non è possibile accedere ai repository dell'app durante questa raccolta dati. Poiché si presume che le pipeline di distribuzione continue si trovino in ambienti isolati, non è possibile superare tali limiti.

Contenuto della richiesta di modifica

I seguenti dati sono inclusi nella richiesta di modifica generata automaticamente:

• Elenco di incidenti di richieste di pull / unione che non sono risolti. Questi dati includono i dettagli dell'asset e l' URL e dell'incidente.

Gli incidenti della richiesta di pull / unione non corretti influenzano la disponibilità della distribuzione della richiesta di modifica. Se vengono trovati degli incidenti di richiesta di pull / merge, sono considerati vulnerabilità e la richiesta di modifica deve essere riesaminata e approvata manualmente.

Esegui pull della richiesta di risoluzione dell'incidente

Gli incidenti di richiesta di pull sono considerati vulnerabilità perché indicano che il codice non controllato è contenuto nelle risorse rilasciate. Per correggere questi incidenti, completa la seguente procedura:

1. Rivedere retroattivamente la modifica unita.
2. Creare un problema su come risolvere eventuali problemi esistenti con il codice.
3. Aggiungere l'etichetta exempt o chiudere il problema di richiesta di pull / unione.

L'autore della richiesta di pull / unione e la persona che chiude il problema di richiesta di pull / unione non può essere la stessa persona.

Risoluzione dei problemi

Caso 1:

| ERROR | 2023-12-20T07:00:48.978Z | index.ts:25:14 | The inventory entry has no such property ('pipeline_run_id').

Problemi noti

• La conformità della revisione peer dipende dall'inclusione della voce di inventario nella fase di rilascio che segue ogni iterazione della pipeline CI (Continuous Integration). Se si ignora l'inclusione della voce di inventario per qualsiasi esecuzione della pipeline CI non riuscita, la prova di revisione peer per quella specifica esecuzione della pipeline CI potrebbe non essere considerata nella pipeline Continuous Delivery (CD).