Riepilogo delle best practice

Di seguito sono riportate alcune best practice sulle cose da fare e da non fare per CI/CD.

Cose da fare:

• Trattare l'infrastruttura come codice

  • Usare il controllo delle versioni per il codice dell'infrastruttura.

  • Utilizzare sistemi di tracciatura/creazione dei ticket sui bug.

  • Chiedere ai colleghi di rivedere le modifiche prima di applicarle.

  • Stabilire i pattern/progetti del codice dell'infrastruttura.

  • Testare le modifiche all'infrastruttura come le modifiche al codice.

• Creare team integrati di sviluppatori composti da non più di 12 membri autonomi.

• Chiedere a tutti gli sviluppatori di eseguire frequentemente il commit del codice nel trunk principale, senza feature branch di lunga durata.

• Adottare in modo coerente un sistema di compilazione come Maven o Gradle in tutta l'organizzazione e standardizzare le build.

• Chiedere agli sviluppatori di creare unit test per una copertura del 100% della base di codice.

• Assicurarsi che gli unit test rappresentino il 70% dei test complessivi in termini di durata, numero e ambito.

• Assicurarsi che gli unit test siano aggiornati e non trascurati. Gli errori che emergono dagli unit test devono essere corretti e non aggirati.

• Considerare la configurazione della consegna continua come codice.

• Stabilire controlli di sicurezza basati sui ruoli (ovvero chi può fare cosa e quando).

  • Monitorare/tracciare ogni risorsa possibile.

  • Creare avvisi su servizi, disponibilità e tempi di risposta.

  • Acquisire, imparare e migliorare.

  • Condividere l'accesso con tutti i membri del team.

  • Pianificare i parametri e il monitoraggio nel ciclo di vita.

• Tenere traccia dei parametri standard.

  • Numero di build.

  • Numero di implementazioni.

  • Tempo medio necessario affinché le modifiche raggiungano l'ambiente di produzione.

  • Tempo medio dalla prima fase della pipeline a ciascuna fase.

  • Numero di modifiche che raggiungono l'ambiente di produzione.

  • Tempo medio di compilazione.

• Utilizzare pipeline differenti per ciascun branch e team.

Cose da non fare:

• Avere branch di lunga durata con merge grandi e complicati.

• Fare test manuali.

• Implementare processi di approvazione, gate, revisioni del codice e revisioni della sicurezza manuali.