Industrialisation des développements Java

Industrialisa+on des développements Java

Chris+an Blavier Benoît Lafontaine

Le 17/03/2010

OCTO, en quelques mots

2 © OCTO Technology -‐ 2010

  Conseil en Architecture et Management des SI

  Un cabinet à taille humaine : 130 consultants fin 2009

  12 ans

  15,4 M€ de CA (2009)

  Un posi+onnement Grands Comptes

  Deux ouvertures à l’interna+onal (Maroc, Suisse)

NOTRE MISSION

  Aider nos clients à maitriser la complexité de leur SI pour en +rer le maximum de valeur

NOS VALEURS FONDATRICES

  L’indépendance vis-‐à-‐vis des intégrateurs et des éditeurs

  L’expérience réelle et pragmaCque des SI stratégiques et des grands projets

NOTRE CULTURE

  La mul+-‐valence : mé+er, technique et communica+on

  L’échange : 25 % du temps réservé à la capitalisa+on des connaissances et des expériences

L’industrialisa+on c’est quoi ?

3 © OCTO 2010

Tests automaCsés

IntégraCon conCnue

Mesure de la qualité

Il ne s’agit pas uniquement des ou+ls de

développement !

Ne pas se tromper d’époque

Une approche où les hommes sont au centre de la démarche


Pourquoi faire de l’intégra+on con+nue ?

Plus un défaut est détecté tard…

…plus il coûte cher à corriger.

© OCTO Technology -‐ 2010 5

€

6

Vous ne voulez plus travailler sans filet de sécurité ? Faites de l’intégraCon conCnue

L’intégra+on con+nue en images


Build

Vérifier la qualité du code

Compiler

Récupérer les dépendances

Déployer

Documenter

Exécuter les tests

Packager

Plateforme de tests

RéférenCel binaires

DocumentaCon & Indicateurs

NoCficaCons

Serveur d’intégraCon conCnue

Build GesConnaire de sources

Build Local

GesConnaire de sources

Build

Vérifier la qualité du code

Compiler


Déployer

Documenter

Exécuter les tests

Packager

L’intégra+on con+nue en images


RéférenCel binaires

Plateforme de tests

DocumentaCon & Indicateurs


Build

Build Local

CVS

Hudson SVN GIT Nexus

NoCficaCons

Les défis de l’intégra+on con+nue

9 © OCTO 2010

Défi #1 : la performance

Défi #2 : éviter l’instabilité du build

Problèmes de performance

Build

Build

Build

Build ... ...


Build

Build

Build Local


:-‐ ( :-‐ (

:-‐ (

Build profilé



Build rapide : tests unitaires

...

Build documentaCon

Build tests intégraCon

Build qualimétrie

... Build packaging

Build complet

Toutes les...

10 min

A la demande

nuits

4 h

nuits

A la demande

Build Local

Build distribué

Serveur d’intégraCon ConCnue


Build documentaCon


Build qualimétrie

Build complet

Build packaging

Build Local


10

240

© OCTO Technology -‐ 2010

Build distribué



Build documentaCon


Build qualimétrie

Build complet

Build packaging

Build Local


10

240

Agent

Agent

(maître)


Applications multi-tout : le défi ?


Tester sur des environnements différents

Pro

Build distribué & plateformes

Serveur d’intégraCon ConCnue (maître)

Build tests interface

Build complet

Build Local


Agent

Agent

Agent

Build tests interface IE 6

Build tests interface Chrome

Build tests interface IE 7

Build tests interface FF


Les défis de l’intégra+on con+nue

16 © OCTO 2010

Défi #1 : la performance

Défi #2 : éviter l’instabilité du build

Instaurer une culture du build


Instabilité du build : le problème


Build


Compiler

Exécuter les tests


Développeurs


Instabilité du build : le défi ?


•  Conserver un référentiel de sources « propre »

•  Empêcher un développeur de bloquer les autres

•  Favoriser l’utilisation décomplexée du référentiel de sources


Une solution : le build incassable


GesConnaire de sources protégé

Développeurs Build


Compiler

Exécuter les tests

20

Outils d’intégration continue


•  Serveur d’IntégraCon –  Hudson –  TeamCity €

–  Bamboo €

–  Pulse € –  CruiseControl –  Apache Con+nuum

–  QuickBuild € –  Team Funda+on Server €

–  LuntBuild


Savoir si son code compile, c’est bien … mais savoir s’il foncConne c’est mieux !

Test Driven Development


Ecrire test en échec

Faire passer le test

Remanier le code

« Outside-‐in » development


Ecrire test en échec

Faire passer le test

Remanier le code

Tests unitaires : cycle TDD répété plusieurs fois pour chaque foncConnalité

Ecrire test de receoe en échec

Faire passer le tests de receoe

Nouveau cycle répété à chaque nouvelle foncConnalité

Pourquoi des tests de receoe automa+sés ?

Conserver la connaissance

• Capitaliser à un endroit unique sur ce que fait effecCvement le logiciel

• Rendre « exécutables » les spécificaCons

Communiquer sans ambiguïté

• Spécifier de façon univoque par les tests

• Minimiser les problèmes de coordinaCon en receoe

Préserver la qualité

• Construire un harnais de tests

• Détecter les régressions au plus tôt

Gagner du temps • Eviter les erreurs manuelles

• Rejouer fréquemment l’intégralité des tests

25 © OCTO 2010

Tests de recehe automaCsés

Plusieurs approches de TDR

26 © OCTO 2010

Tests d’IHM

SpécificaCons exécutables

Behavior Driven Development

Tests d’IHM

27 © OCTO 2010

Selenium

WaCr

Certains ou+ls disposent d’un mode d’émula+on du navigateur, plus rapide

Le pour, le contre …


Inconvénients

Enregistrés / écrits par des développeurs

Temps d’exécution

Quasi exhaustifs ;-)

Avantages

Quasi-exhaustifs

Rassurants pour le métier


29 © OCTO 2010

Tests d’IHM



Dites le avec un tableau !


Utilisateur! !Mot de passe! !Message�

jdoe ! ! ! !elephant! ! ! ! Echec ! �

dgray! ! ! toto ! ! ! !Echec ! �

dcooper! ! d1ane4ever! ! ! Succès !! !�

. . . ! ! ! ! !. . . ! ! ! ! !. . . !�

Règle de gestion : création de compte�Lors de la création de compte, un utilisateur doit obligatoirement choisir un mot de passe contenant des lettres et des chiffres �

Par exemple : GreenPepper


Par exemple : GreenPepper


Spécifica+ons exécutables

33 © OCTO 2010

Système testé

Pages de tests wiki

Code de liaison

(fixtures)



Inconvénients

Par défaut ne permet pas de tester une IHM

Pourrait être encore plus expressif

Avantages

Expressivité : les tests peuvent être formulés par des utilisateurs

On peut fusionner tests et documentation


35 © OCTO 2010

Tests d’IHM



Et si on racontait une histoire ?

36 © OCTO 2010

Etant donnée … [ un contexte ] �

Quand … [ un événement ] �

Alors… [ un état attendu ] �

BDD (Behavior Driven Development), une manière de formaliser ses histoires :

BDD avec Cucumber


BDD, a new genera+on


Evolution syntaxique de TDD Orienté développeur Tout est dans le code

Tests d’acceptance Prise en compte du reste de l'équipe Extraction des scénarios


39 © OCTO 2010

Inconvénients

Pas d’outils collaboratifs

L’intégration de cucumber avec le monde Java est peu documentée

Avantages

Extrêmement expressif

S’intègre très naturellement avec un outil de test d’IHM

L’avenir du test d’acceptance automatisé


On n’améliore que ce que l’on mesure

http://www.flickr.com/photos/55145236@N00/146617178/

Quels indicateurs ?

•  Indicateur de « le code compile » : le Build –  Eviter le « ça compile sur mon poste » –  Ou+ls : Hudson + Maven

•  Indicateurs de bonne santé : tests automa+sés –  Ou+ls : XUnit, Surefire, JCoverage / Cobertura …

•  Indicateurs de la qualité du code : analyse sta+que –  Ou+ls : PMD, CheckStyle, Findbugs –  Aggrégateur : Sonar



Jusqu’ici tout va bien

Mesurer les tendances


Mesurer les tendances


Les indicateurs subjec+fs


http

://w

ww

.info

q.co

m/n

ews/

2007

/08/

agile

-kan

ban-

boar

ds

Mesurer la produc+vité ?

Débit de foncConnalités


Le nombre de fonc+onnalités, pondérées par la valeur mé+er, ajoutées au logiciel pendant un laps de temps

donné et répondant aux exigences qualités

Récapitulons

•  Repousser les limites de l’intégra+on con+nue –  Profiler et distribuer les builds –  Meore en place une poli+que de build incassable

•  Automa+sez vos tests de receoe –  En suivant des cycles de développement « outside-‐in »

–  En impliquant votre MOA, grâce à des ou+ls conviviaux

•  Mesurer pour s’améliorer –  Privilégier un ensemble d’indicateurs, objec+fs et subjec+fs

–  Mesurer la produc+vité


Université du SI 2010 Le rendez-‐vous des geeks et des boss
