Continuous Deployment - Agile Day 2010
- 1. Continuous Deployment CheckIn2Production Andrea Chiarini Claudio Pattarello
- 3. Continuous Deployment • La checklist (“eh… ma questo non era nella checklist…”) • Costruttivo dialogo con i sistemisti (“non va un… #@”£%$!!!!!”) • Configurazioni ambienti (“mah… sulla mia macchina andava…”) • L’attività (giornata) di rilascio (“dai, facciamo fare il rilascio a quello nuovo?”) • L’esperto non è in sede (“dai, è solo mezzanotte, chi ha il cellulare di Franco?”) • La nuova release è in produzione (“porca… come si fa rollback???”) • Il rollback è in produzione (“porca… ma cos’abbiamo cambiato???”) • Fix delle release in produzione (“allora, fai così, apri il DB e cancella quella riga, poi…”) Si può proseguire per tutta l’ora….
- 4. Continuous Deployment Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Martin Fowler The high level of our process is dead simple: Continuously integrate (commit early and often). On commit automatically run all tests. If the tests pass deploy to the cluster. If the deploy succeeds, repeat. Timothy Fitz Continous Deployment is the practice of releasing every good version of your software, often multiple times a day. Jez Humble
- 5. Continuous Deployment Commit stage Build Unit Test Packaging Functional Acceptance Testing Nonfunctional Acceptance Testing Manual Testing Exploratory tests Demo Release
- 7. Continuous Deployment Release Candidate Release in production Production Data Application Configuration Environment Configuration
- 8. Continuous Deployment Come è composto un sistema di Continuous Deployment?
- 9. Continuous Deployment • Sistema Continuous Integration •Sistema reattivo ad ogni check-in •Scheduler in grado di gestire una coda di task •Compilazione e testing su macchine diverse da quelle di sviluppo •Sistema di feedback sullo stato di ogni step del processo di integrazione • Configuration management •Gestire le configurazioni collegate ad ogni versione dell’applicazione per un particolare environment •Conoscere e versionare tutte le configurazioni che caratterizzano l’ambiente di esecuzione per ogni versione dell’applicazione
- 10. Continuous Deployment • Script automatici di deploy/rollback • il deploy di un’applicazione è demandato ad un singolo grosso bottone rosso • il rollback di un’applicazione è demandato ad un singolo bottone rosso più grosso di quello precedente • Ambienti di test • Possibilità di creare e distruggere rapidamente ambienti di test • Possibilità di configurare automaticamente questi ambienti come la produzione • Versioning • Mantenimento nel repository di tutte le configurazioni, applicative e di environment • Mantenimento nel repository di tutti gli script che costitiuiscono il sistema di continuous deploy
- 11. Continuous Deployment Vantaggi • riduzione del tempo di deploy di una feature / bug fix • eliminazione degli errori commessi in fase di deploy • eliminazione delle sorprese in fase di deploy • aumento frequenza di rilascio, con modifiche più incrementali portate in produzione • è un sistema modulare, posso implementarlo un passo alla volta (continua)
- 12. Continuous Deployment Vantaggi (continua) •Il sistema è autocontrollato, qualsiasi difetto nel processo si evidenzia subito e non quando ne ho bisogno • Accorciamento ciclo di apprendimento • New entry nel team con curva di apprendimento molto bassa • Sviluppatori concentrati sulle feature e non sui rilasci • Rafforza collaborazione con gli altri stakeholder del progetto
- 13. Continuous Deployment Svantaggi • sistema costoso da creare (costi hardware e tempo di messa in opera) • sistema costoso da manutenere • richiede forte disciplina da parte del team • più l’ambiente è complicato più lo sarà il sistema di C.D. • richiede l’accordo e la partecipazione di tutti gli stakeholder (management, utenti, sistemisti)
- 14. Continuous Deployment “Ma si mette su tutto insieme o posso farlo un pezzo alla volta?” “Ma può funzionare in un team di grosse dimensioni?” “Ok, ma mi serve veramente?” “Quanto mi viene a costare una roba simile?” “Io non ne ho bisogno.” “E’ impossibile catturare tutte le configurazioni del mio ambiente!” “Quindi dovrei fermare i server per un rilascio tutte le volte che faccio check-in???” “Io ho già un sistema di Continuous Integration ed è sempre rosso…” “Come faccio a capire quanto tempo perdo ogni volta per rilasciare?” “Riesco a farlo su un progetto già in corso o devo per forza metterlo su fin dall’inizio?” “Bello, ma il mio manager non l’accetterebbe mai…” “Non ci riuscirò mai in un ambiente legacy…” “Ma ci sono anche delle aziende vere che lo fanno???” “Come posso fare per un applicazione desktop?”
- 15. Continuous Deployment Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by David Farley and Jez Humble ThoughtWorks C.I. Feature Matrix http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix GrokAndRoll Sporadic delivery of thoughts on continous delivery http://grokandroll.com/ Case Study: Continuous deployment makes releases non-events http://www.startuplessonslearned.com/2010/01/case-study-continuous-deployment-makes.html
Editor's Notes
- #3: Tutti voi fate dei rilasci (altrimenti non consegnate) Avete quindi già un sistema di deploy Cosa succede quando rilasciate?
- #4: Tutti voi fate dei rilasci (altrimenti non consegnate) Avete quindi già un sistema di deploy Cosa succede quando rilasciate?
- #5: Jez Humble autore con David Farley di Continous Delivery etc.. Etc… della Adison Wesley Timothy Fitz – Head Engineer alla IMVU (social network, 50 milioni di utenti)
- #6: Introduzione Continous Integration
- #15: Ma ci dovrebbero lavorare gli sviluppatori o i sistemisti? Che differenza c’è tra C.Delivery e C.Deploy? TALK CP: bene Andrea tutto questo è molto bello… ma mi sembra molto oneroso il suo realizzo AC: Ma quanto costa fare un rilascio in un sistema non automatizzato? Non devi fare tutto subito, ma puoi costruirlo a step (slide 5) CP: Si ma non posso fermare i server ad ogni check-in AC: differenza fra c. deployment e c.delivery, la decisione della delivery diventa del business (management/politica/marketing) CP: in un sistema prettamente legacy non è applicabile AC: macchine virtuali, simulatori, emulatori, etc automatizzare tutto il possibile, ciò che è automatico non fa errori CP: quando ho un ambiente enterprise, probabilmente ho più sistemi che parlano tra loro, BizTalk, SqlServer, Host, AC: l’ambiente di deploy deve essere una copia di produzione. Ogni cosa che non puoi duplicare rimarrà come possibile marone CP: i sistemisti non sono mie amici, sono sicuro che mi remeranno contro. AC: i sistemisti diventano co-autori del sistema (responsabilizzazione, partecipazione al processo)
- #16: Ma ci dovrebbero lavorare gli sviluppatori o i sistemisti?