Formazione scritta DevOps
Perché introdurre un processo di revisione continua per garantire la qualità?
Le organizzazioni si affidano molto a revisioni, audit, ispezioni e approvazioni subito prima dei deployment in produzione. Queste ispezioni sono in genere svolte da persone coinvolte solo marginalmente nel lavoro, ammesso che lo siano. Peggio ancora, a volte chi deve ispezionare e approvare ha una comprensione errata del lavoro, quindi devi istruirlo proprio quando vuoi distribuire il codice in produzione.
Problemi dei meccanismi di controllo esterni
Nella maggior parte delle organizzazioni è più facile creare controlli che instaurare fiducia reciproca. Aggiungere domande ai moduli di controllo delle modifiche, introdurre ulteriori livelli gerarchici di approvazione e richiedere più tempo per comprendere e approvare le modifiche sono quindi problemi tipici dei controlli esterni.
Negli ambienti con poca fiducia e una cultura di comando e controllo, molti incidenti sono destinati a ripetersi. Si crea un circolo vizioso perché manca trasparenza sul lavoro effettivo e sui problemi ricorrenti e il lavoro viene svolto in grandi lotti per limitare al massimo i deployment difficili. I tempi di rilascio più lunghi danneggiano la competitività nel time to market. Feedback lenti, tardivi e privi di indicazioni concrete impediscono ai team di imparare dagli errori.
Un'organizzazione DevOps competente come la tua sa che chi è più vicino al lavoro e ai problemi connessi li conosce meglio. Ulteriori controlli e approvazioni esterni non aggiungono valore al flusso. Si arriva così alla più grande sfida di gestione e leadership del nostro tempo: creare culture di fiducia in cui il lavoro sia trasparente e rispetto autentico e fiducia reciproca siano alla base del lavoro quotidiano.
Riduci la dipendenza dalle ispezioni periodiche e affidati alle revisioni tra pari nel lavoro quotidiano. Fai collaborare costantemente sviluppatori, ingegneri operativi, specialisti della qualità e della sicurezza delle informazioni nel team DevOps, affinché rivedano il lavoro reciproco e rendano possibili deployment sicuri.
Coordinare attività complesse senza controlli esterni
Un progetto è già complesso quando ci lavora un solo team, ma può diventarlo ancora di più quando più team lavorano su componenti diversi dello stesso sistema. Alcune misure che possono aiutare te e il team DevOps a gestirlo al meglio sono:
- I comitati per le modifiche composti da persone esperte della materia, anziché soltanto da dirigenti, possono aiutare a individuare le dipendenze tra team prima che avvengano le modifiche.
- Le architetture debolmente accoppiate basate su SOA e microservizi riducono le dipendenze e lo sforzo di comunicazione.
- I rappresentanti tecnici dei team DevOps dovrebbero individuare le dipendenze e le sequenze di sviluppo e deployment.
- Comunicare di continuo tramite piattaforme di chat condivise per coordinare le modifiche, capire come le interpretano gli altri e verificare la loro comprensione.
- Le modifiche più incisive e rischiose, come le migrazioni o le modifiche infrastrutturali, richiedono prove negli ambienti di test e contromisure tecniche come meccanismi di failover e rollback completo.
Le organizzazioni DevOps più performanti si affidano soprattutto alle revisioni tra pari e meno alle approvazioni esterne
Molte importanti organizzazioni DevOps, tra cui Amazon, Netflix, Etsy e GitHub, usano un processo di revisione e deployment tramite «pull request». Ecco come funziona:
- Chi sviluppa crea un ramo di sviluppo separato a partire dal trunk. Il ramo non dovrebbe durare più di pochi giorni lavorativi e deve avere un nome chiaro e descrittivo come «login-screen-v2». Il lavoro si svolge in locale sulla propria postazione e il ramo viene registrato regolarmente nel sistema di controllo di versione.
- Quando ritiene che il ramo sia pronto per essere integrato nel trunk, chi sviluppa apre una pull request per chiedere una revisione.
- Dopo aver ricevuto i commenti e l'approvazione dagli altri membri del team DevOps, integra il codice nel trunk. Poi lo distribuisce nei sistemi di produzione.
Per modifiche di rilievo, come quelle agli schemi dei database o alla sicurezza delle applicazioni, chi sviluppa può inviare altre pull request per ricevere feedback da specialisti dell'organizzazione, come amministratori di database o specialisti di sicurezza delle informazioni.
Anche durante le revisioni del codice applica il principio dei lotti piccoli. Altrimenti la revisione richiede più tempo e grava molto su chi la svolge. Quando la modifica cresce, il rischio aumenta esponenzialmente e la revisione diventa meno affidabile. Se è troppo grande e difficile da capire, puoi chiedere a chi ha scritto il codice di suddividerla in parti più piccole e comprensibili.
Ogni persona nel team DevOps, a prescindere da anzianità ed esperienza, deve far rivedere le proprie modifiche. Tutti dovrebbero monitorare il flusso dei commit, così gli eventuali conflitti vengono individuati e risolti prima che causino problemi più grandi nella pipeline o, peggio, durante i deployment in produzione.
La programmazione in coppia, da sola o combinata con lo sviluppo guidato dai test (TDD), con una persona che scrive il codice dell'applicazione e l'altra che scrive il test automatizzato, può permettere al team DevOps di rivedere il codice mentre viene scritto. A parità di dimensioni del team e requisiti del progetto, si è misurato e dimostrato che richiede il 15% di tempo in più, ma riduce gli errori di codifica dell'85%. È quindi una pratica importante da valutare con il team DevOps.
Valuta anche revisioni in affiancamento, notifiche automatizzate dei check-in e strumenti che facilitano le revisioni e migliorano la qualità del codice.
CONCLUSIONE
Rendi ciascun team DevOps responsabile della qualità dei propri risultati. Crea una cultura che dia alle revisioni del codice continue e di qualità lo stesso valore che dà alla scrittura di codice di qualità.
