Principi di Continuous Delivery ( automatizzare i rilasci )

8 Principi di Continuous Delivery
1) Il processo per il rilascio / distribuzione del software DEVE essere ripetibile e affidabile . Questo porta al 2 ° principio ...

2) Automatizzare tutto! Una distribuzione manuale può mai essere descritta come ripetibile e affidabile (non se lo sto facendo!). Bisogna investire seriamente automatizzando tutte le mansioni che fate ripetitivamente, e questo tende ad accrescere la affidabilità.

3) Se qualcosa è difficile o faticosa, falla più spesso. Superficialmente questo suona stupido, ma in fondo questo significa che facendo qualcosa di difficoltoso, più spesso, vi porterà a migliorare, probabilmente automatizzando, e questo finirà per renderlo indolore e facile. Prendiamo ad esempio fare una distribuzione di uno schema di database. Se questo è difficile, si tende a non farlo molto spesso, ad evitarlo, facendolo forse una volta al mese. In realtà ciò che si dovrebbe fare è migliorare il processo di distribuzione delle implementazioni dello schema, diventando bravi a farlo, e farlo più spesso, ripetendolo anche una volta al giorno se necessario. Se fai qualcosa ogni giorno, troverai il modo di renderla migliore rispetto piuttosto che la si fa una volta al mese.

4) Tenere tutto codice sorgente versionato e sotto controllo - questo suona come un po strano oggi, ma parlo seriamente, chi tiene tutto il codice sorgente versionato? A quanto pare poche persone. Lo sapevate?

5) "Fatto" significa "Rilasciato". Ciò obbliga a lavorare su di un progetto fino a quando non è nelle mani degli utenti, e funziona correttamente. Non c'è, quindi, niente del tipo: "ho controllato nel mio codice quindi è fatto per quanto mi riguarda". Ho avuto la fortuna di lavorare con alcune squadre di software che con entusiasmo si assicuravano che le loro modifiche al codice stavano funzionando correttamente fino al momento in cui i loro cambiamenti erano in produzione, controllando, anche, il sistema live per assicurarsi che i loro cambiamenti erano avvenuti con successo. D'altra parte ho lavorato con squadre in cui la loro responsabilità finiva dopo aver controllato il loro codice per il VCS.

6) Costruire qualità! Prendete il tempo ed investite nelle metriche di qualità. Un progetto con buone metriche di qualità mirate (potremmo parlare di copertura di unit test, di code styling, di violazione delle regole, misure di complessità - o, preferibilmente, di tutto ) sarà sempre meglio di uno senza, e più facile da mantenere nel lungo termine.

7) Ognuno ha la responsabilità del il processo di rilascio. Un programma in esecuzione su un computer portatile di uno sviluppatore non sta andando a fare i soldi per la società. Allo stesso modo, un progetto senza un piano per la distribuzione non sarà mai pubblicato, e quindi non fa fare soldi. Le aziende fanno i soldi, da sempre, solo con prodotti rilasciati ai clienti, quindi, questo processo dovrebbe essere nell'interesse di tutti. Gli sviluppatori dovrebbero sviluppare progetti tenendo a mente come distribuirli. I project manager devono pianificare progetti con attenzione alla distribuzione. Tester dovrebbero verificare i difetti di distribuzione con la stessa cura e attenzione che impiegano per i bug del codice (e questo dovrebbe essere automatizzato e integrato nella attività di distribuzione stesso).

8) Migliorare continuamente. Non sedersi e aspettare che il sistema diventi obsoleto o impossibile da mantenere. Miglioramento continuo significa che il sistema sarà sempre in evoluzione e quindi più facile da cambiare quando ce ne sarà bisogno.

 Per usare al meglio questi principi
ci sono anche: 4 Best Practise di Continuos Delivery

 1) Compilare i binari solo una volta. Rimarreste attontiti per il numero di volte che ho visto gente ricompilare il codice tra un ambiente e l'altro. I binari devono essere compilati una sola volta e una sola volta. Il binario deve quindi essere conservato in un posto che è accessibile solo per il meccanismo di distribuzione e il meccanismo di distribuzione dovrebbe schierare lo stesso binario per ogni ambiente successivo ...

 2) Utilizzare esattamente lo stesso meccanismo per distribuire in ogni ambiente. Sembra ovvio, ma ho visto sinceramente casi in cui sono state automatizzate le distribuzioni di Test e solo per le distribuzioni di produzione applicare procedure manuali. Ho visto anche casi in cui sono stati entrambi automatizzati, distribuzioni di Test e di produzione, ma in due lingue completamente diverse. Questo è ovviamente un lavoro da pazzi.

 3) Smoke test di rilascio. E' necessario non lasciare al caso che il rilascio sia un successo strepitoso, scrivere un test di funzioni base (smoke test) e includerli nel processo di distribuzione. Mi piace anche includere un semplice test diagnostico, tutto quello che è possibile fare per controllare va fatto e tracciato - si confronta un elenco di file e quello che ci si aspetta è di vedere la vostra distribuzione in quello che realmente finisce sul server. Io lo chiamo un test di diagnostica perché è un buon primo porto di scalo quando c'è un problema.

 4) Se qualcosa va storto, ferma la linea! Butta via e ricomincia da capo il processo, non modificare, non fare hack. Se si verifica un problema, non importa dove, scarta la distribuzione (cioè fai rollback), risolvi il problema correttamente, controllare nella versione del codice sorgente e ripeti il processo di distribuzione. Un sacco di gente dice che questo è impossibile, soprattutto se hai una finestra di interruzione per distribuire le cose nel vostro sistema live limitata, o se le modifiche di produzione finiscono nel bel mezzo della notte, mentre nessun altro è in giro per fixare adeguatamente la issue. Direi, invece, che questi argomenti colgono il punto. In primo luogo, se si dispone solo di una piccola finestra di interruzione, hacking del sistema live dovrebbe essere l'ultima cosa che vorrei fare, perché questo farà decadere tutti gli altri ambienti a meno di hackerare similmente tutti gli ambienti. In secondo luogo, la prossima volta che fate un rilascio, si può riprodurre il problema originale. In terzo luogo, se si sta facendo il rilascio nel bel mezzo della notte con nessuno intorno per risolvere i problemi, allora non stai prestando sufficiente attenzione al 7 ° principio di Continuos Delivery - Ognuno ha la responsabilità per il processo di rilascio. Almeno che non sia indispensabile, non mi consiglia di fare rilasci quando c'è la minima quantità di supporto disponibile e di personale, va semplicemente contro il buonsenso.