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
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
Tutti voi fate dei rilasci (altrimenti non consegnate)
Avete quindi già un sistema di deploy
Cosa succede quando rilasciate?
Tutti voi fate dei rilasci (altrimenti non consegnate)
Avete quindi già un sistema di deploy
Cosa succede quando rilasciate?
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)
Introduzione Continous Integration
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)
Ma ci dovrebbero lavorare gli sviluppatori o i sistemisti?