You are on page 1of 27

Continuos Integration & Extreme Programming

R. Turco

Filosofie, Processi, Metodologie

2

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 un’unica 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

3

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 l’effort aumenta esponenzialmente con: o numero di bug o numero di componenti sw/hw o tempo trascorso dall’ultima integrazione
L’idea è 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 l’OO 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 un’architettura 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)

5

6

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 dell’infrastruttura, 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: l’idea è 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.

8

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. L’effetto è 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 dall’analisi 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 d’accesso separate Svantaggio: aumenta l’effort 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 d’uso 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 dell’ambiente di produzione  Rendere facile individuare l’ultima 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) Microsoft’s Team Foundation Server (commerciale) Sin ThoughtWorks’ Go (commerciale) Urbancode’s 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 l’Extreme 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