Continuos Integration & Extreme Programming

R. Turco

Filosofie, Processi, Metodologie

Premesse
Dal 1980 in poi sono nate nuove filosofie e ottime metodologie: ITIL, CMM, XP, TDD Processi e metodologie sono best practices consolidate in vari anni Le best practices non sono una panacea per tutto, n portano ad ununica soluzione Sostanzialmente esse cercano di rendere le attivit coordinate, ripetibili industrialmente, definite e ottimizzate Insegnano, in varie forme, di esercitare bene le responsabilit Plan, Do, Check, Act (PDCA) Necessitano comunque di un oculato tailoring, una customizzazione del processo rispetto ai propri task e progetti Il Project Manager si deve sforzare sempre a trovare un equilibrio tra vari elementi non ortogonali del processo:
Utilit, Efficacia, Efficienza (Processo Agile e Light) Portata delle User Stories (e relativa Pianificazione) Qualit Tempo

Premesse
Definizione da Wikipedia : In software engineering, continuous integration (CI) implements continuos processes of applying quality control small pieces of effort, applied frequently Questo perch in un progetto sw leffort aumenta esponenzialmente con: o numero di bug o numero di componenti sw/hw o tempo trascorso dallultima integrazione
Lidea di rimpiazzare una grande fase di integrazione con tante fasi, qualitative, frequenti, costituite da piccole integrazioni e refactoring, mantenendo il processo di sviluppo sempre in esecuzione, nel senso letterale della parola.
E, quindi, una metodologia innanzitutto nelle mani del team di realizzazione, ma riusabile anche in altri settori di responsabilit.
Mentre lOO fonde e sfuma le fasi di Analisi e Sviluppo, il CI fa lo stesso con il resto del processo di sviluppo.
Articolo consigliato : http://martinfowler.com/articles/continuousIntegration.html 4

Martin Fowler

Creare un utile processo di Continuos Integration

Il dilemma principale come creare un processo di Continuos Integration utile, efficiente, efficace che consenta un processo ed un prodotto di qualit. Ogni processo/metodologia ha bisogno di strumenti a supporto. Uno strumento a supporto del Continuos Integration uno strumento che deve anticipare nelle fasi iniziali gran parte dei problemi di integrazione, ovvero in una fase in cui la progettazione ancora efficace a correggere il tiro per ottenere unarchitettura pulita, un progetto software che segue le best practices (Design Pattern, framework, prototipo etc). Proprio per questo il Continuos Integration si sposa bene con processi prototipali e di iterazione, con test e refactoring continuo, come Extreme Programming (XP) e Test-Driven Development (TDD).

Nota: Per XP vedi http://www.extremeprogramming.org)

Creare un utile processo di Continuos Integration

I problemi di integrazione sono tipicamente di: coerenza del sw sul repository (n sviluppatori che committano sul repository), qualit del software (metriche di complessit, di rami secchi, duplicazioni, bugs), documentazione per chi deve riusare il sw appena sviluppato, test unitari, test di business o di scenario (con verifica della copertura), test di regressione automatici, tempi di esecuzione, logging e configurabilit, test di carico per verifica dellinfrastruttura, build del sw, deploy del sw, sw distribution sui server, etc

Ogni problema di integrazione se scoperto tardi tende ad aumentare i rischi e a creare punti oscuri nelle pianificazioni.
7

Filosofia del CI Il server CI lavora continuamente e guida la qualit, catturando dati e pubblicandoli: lidea di fare tanta piccola qualit, da affinare ogni volta. Tempo fa il sw era progettato e realizzato come una abitazione, con solide fondamenta - il pi delle volte - fatte con pilastri di cemento armato, ma quasi sempre con pareti di carton-gesso! Nel sw engineering la qualit non si pu acquistare ma si deve introdurre a step iterativi (Quality is free!). Chi pu usare il CI Ogni tipologia di progetto e/o team; adatto anche ai team distribuiti geograficamente. Sono preferibili i progetti iterativi, prototipali con XP e TDD. Quando usare il CI Ad inizio di un nuovo progetto (cum grano salis) e durante lo sviluppo (not just a compiling!) e con visibilit e utilit per tutti gli attori dello sviluppo.

Gli effetti ottenibili (il valore aggiunto)

Si riducono i rischi: sono pi facili le predizioni e ci sono meno punti ciechi nel progetto. I problemi vengono rilevati in anticipo (Timely Feedback). Le integrazioni non sono pi lunghe e difficile da prevedere come durata.

Si riducono le attivit manuali, aumentano i check-in, aumenta il tempo di progettazione e sviluppo (incoraggia il Constant Design Improvement), aumenta la qualit del sw (Coding Standard), aumenta il tempo per le analisi e le fix, aumenta il deploying ed il test di sw distribution, migliora la produttivit. Aumenta la confidenza del team col sw e aumenta il senso di ownership comune del software (Collective Code Ownership)
9

Il build self-testing riduce il backlog dei bugs; le regressioni automatiche dei test salvano tempo e permettono di adattare meglio il progetto al cambiamento I bug in fase di sviluppo vengono rimossi rapidamente e facilmente, evitando che si accumulino e che facciano aumentare la complessit di sviluppo e test. Leffetto che a lungo termine, in collaudo e produzione, tendenzialmente si riducono i bug sw rilevati. Quando i test falliscono possibile usare una tecnica di diff debugging termine introdotto da Martin Fowler cio disponendo di una build che confronta automaticamente i sorgenti tra una build e la successiva, accelerando i tempi di individuazione. In tal modo vengono rilevate le differenze dove, al 99%, localizzato il bug introdotto nella seconda build. Le differenze sono note anche a coloro che non sono stati gli autori delle modifiche. Le Best Practices di programmazione sono suggerite dallanalisi statica del sw ad ogni build (con checkstyle, findbugs, etc, ovvero plugin analoghi a quelli di Eclipse), mantenendo alta la qualit del sw da parte dei programmatori.

10

Ogni build pu essere taggata, in modo che sia riconoscibile la versione di tutti gli artefatti della build. Uno strumento in tal senso utile a verificare la versione. Le catene di test di stress massivo e multi-thread possono aiutare a individuare problemi infrastrutturali ei limiti di carico a cui il sistema o il prototipo pu resistere Si ha una completa history del progetto e di chi accede al server Jenkins Un unico strumento condiviso tra Team Development e Team Build Manager, ma consigliabile su server Jenkins separati o se identico con utenze daccesso separate Svantaggio: aumenta leffort iniziale per organizzarsi in termini XP+CI e implementare le Build Jobs di Jenkins Curiosit: Esistono molte offerte di cloud computing PaaS che offrono server virtuali e Jenkins come server per il proprio CI! (es: OpenShift di RedHat https://openshift.redhat.com, Cloudbees, Shining Panda etc )

11

PIPELINE OF BUILDS (7 steps)

Build Quality Build di Documentazione duso Build di diff debugging Build di Test automatico a) Build sw b) Deploy c) Distribution

Responsabilit?
Project Manager e Team di Realizzazione

Responsabilit?
Build Manager e Team di Build

Jenkins 1

Jenkins 2

Quando?
Durante lo sviluppo del sw

Quando?
Durante la build sw

(Timely Feedback: Risposta tempestiva)

Output
sviluppo sw, Checkstyle, Findbugs (vulnerability), Complexity, Produttivit

Output
Javadoc

Output
Individuare bug grazie alle differenze dei sorgenti tra due build

Output
Copertura test Tempi di esecuzione Correttezza Funzionale/Non Funzionale Esercibilit (log, etc) Usabilit

Output
Build del software Uso coerente delle risorse come librerie, memoria, etc

UML
(Modalit di documentazione standardizzata)

Azioni?

Azioni?

Le azioni correttive hanno senso durante lo sviluppo del sw e prima del test del collaudo

Durante la build sw

12

Gli step classici di build sw, deploying, distribution sono solo i 3/7 della pipeline

Pipeline of builds
qualit
doc diff debugging test build sw deploying distribution

13

I pattern di Martin Fowler per un CI corretto

Disporre di un source repository centralizzato Automatizzare le build (not just compiling!) senza configurazioni manuali Rendere le build self-testing Committare frequentemente sul source repository Lanciare le build su una macchina di integrazione dedicata Mantenere la build veloce (metriche, statistiche come job a parte) Fare il test su un clone dellambiente di produzione Rendere facile individuare lultima versione di build corretta (labeling o targeting) Ognuno deve vedere cosa succede (ed esserne notificato) Automatizzare il deploying

14

Quale strumento
Esistono molti prodotti commerciali e non sul mercato per il Continuos Integration, per ogni linguaggio (vedi http://en.wikipedia.org/wiki/Continuous_integration):
Apache Continuum Apache Gump Beebox Bitten Cabie CruiseControl e CruiseControl.NET Draco e Draco.NET Jenkins CI (ex Hudson) Jetbrains Team City (commerciale) Microsofts Team Foundation Server (commerciale) Sin ThoughtWorks Go (commerciale) Urbancodes Anthill Pro (commerciale) etc.

Tutti i prodotti si basano su quanto il team di sviluppo ha gi implementato: pom (Maven), JUnit, Simulatori etc; Altri elementi di scelta del prodotto sono: filosofia partire in piccolo, per iniziare a comprendere Scegliere un qualcosa di semplice, intuitivo ed estendibile;

15

Jenkins CI Open Source, scritto in Java ed un war che gira in un web container creato da Kohsuche Kawakuchi in casa Sun come Hudson, acquisito, poi, da Oracle.
ha una grande Community su Internet che lo sostiene, affiliato con Software in the Public Interest (SPI) NPO

ha una provata stabilit e semplicit usato da NASA, Uk Government, Deutsche Telecom, Alcatel, Yahoo!, Michelin, Sony etc. utilizzabile con sistemi operativi diversi (Linux, Windows, etc) utilizzabile per molti linguaggi e browser (Java, Groovy, Grails, Gradle, C, C++, Visual Studio, .NET, Ruby, PHP, Python, etc)

16

utilizzabile con qualsiasi repository CM ( Clear Case, TFS, SVN, GIT, PVCS, etc) molti i plug-in disponibili
estensibile, si possono sviluppare in proprio plug-in in Java su tematiche particolari

fornisce una console di comando centralizzata, facilmente configurabile e di monitoraggio del processo esiste un testo libero su Internet: Jenkins the definitive guide dispone di un sito con molta documentazione si basa sugli strumenti sviluppati (pom maven, ant, shell, cmd, test con JUnit)

17

A polling o a commit sul CM repository (Build Trigger):

fa una verifica della coerenza del sw fa una build con maven (o con ant o altro) del sw presente sul repository CM consente pre-azioni e post-azioni alle build generiche produce documentazione javadoc e UML del sw (reverse) lancia i test di JUnit unitari o di scenario funzionale (sequence) e produce i report lancia i test multithread massivi e produce i report fornisce la copertura dei test produce le metriche (LOC, complexity, codice duplicato chechstyle, cerca bug potenziali etc) permette di stabilire la produttivit del team dalle metriche (es: LOC/time in day) permette le installazioni (deploy) permette la software distribution inoltra email degli errori di build alle persone inoltra email con i link dei report ai manager Sono coperti tutti i pattern di Martin Fowler
18

La filosofia di base per un CI pratico racchiusa in poche regole cum grano salis:
Ridurre gli effetti di resistenza psicologica del team Non mettere il carro davanti ai buoi Fare le cose utili al momento giusto (durante) Seguire, con giudizio, il corso naturale del progetto Usare un processo iterativo, come ad esempio lExtreme Programming (XP)

Le fasi sono semplicemente: Fase 1: Inizio progetto nuovo (Watch Code nel Team di Sviluppo) si sviluppa e si collega Jenkins al CM Repository per build metriche, documentazione javadoc e UML (build documentale e di metriche come monitoraggio del sw) Fase 2: per ogni parte completata (Build Product nel Team di sviluppo) si dispone di parte del sw e dei POM si predispongono le build sw con Jenkins con finalit diverse dal Build Team
19

Fase 3: Integrazione e test (Run Tests e Publish Results nel Team di sviluppo) si predispongono i test unitari e di scenario con Jenkins si collegano i test a Jenkins per l'automazione Si ottengono metriche di produttivit, copertura dei test interni Fase 4: Build Product e Publish Results (nel Team di Build) Si coopera col Team di Build Si ottengono ulteriori metriche

20

Architettura pratica

21

Report - Metriche

22

Report Job builds

23

Report - 3

24

25

Report copertura dei test

26

27