Présentation d'Oxiane à Devoxx France 2013 sur le sujet de l'usine logicielle : "de compiletout.bat à l'usine logicielle pour java"

1. 15h35 - 16h25 - Salle E. Fitzgerald & L. Armstrong
De compiletout.bat à
l’Usine Logicielle pour Java

2. 27 au 29 mars 2013
De compiletout.bat
à l’Usine Logicielle pour Java
Guillaume Rams
Consultant/Formateur, Oxiane
@GuillaumeRams

3. Guillaume Rams
• 15 ans dans le monde Java
› SSII, recherche, start-up, éditeur de logiciels, conseil, formation, …
• Consultant / Formateur pour Oxiane
› Filière Usine Logicielle : Intégration Continue, Qualimétrie, Eclipse, …

4. 27 au 29 mars 2013
De compiletout.bat à
l’Usine Logicielle pour Java
• Ce que j’entends par Usine Logicielle
• Ce que ça contient
• Comment l’héberger
• Qui est le Responsable d’Usine Logicielle

5. Qu’est-ce qu’une Usine Logicielle ?

6. Plusieurs visions du développement
•Classique :
une chaîne de fabrication du logiciel, depuis les sources
jusqu'au livrable
•Tendance DevOps :
l'ensemble des outils allant des demandes à leur mise en prod’
et leur exploitation
•Tendance XP :
une équipe qui prend des besoins du client et produit du
logiciel fonctionnel

7. L’Usine Logicielle selon la R.A.C.H.E.
• Je partage mes sources
dans CVS
• Je code dans Eclipse
• Bouton droit -hop-
exporter EAR
• La console Websphere,
et -hop- c'est déployé
• Et la variante :
FTP -hop- puis envoi de mail « ça y est j'ai livré l'EAR »

8. L’Usine Logicielle ou Software Factory
•Automatiser et outiller au
maximum toutes les activités
liées au développement
(afin de)
•Maximiser la quantité de
travail à ne pas faire par
les développeurs
(et enfin faire ce qui aurait été trop pénible manuellement)

9. Ce que contient l’Usine Logicielle

10. De l’idée au logiciel
Logiciel
Idée

11. – Précision –
Ceci n’est pas un cycle en V.

12. Les limites de l’analogie
Contrairement à une usine concrète,
nous ne produisons pas le même code source à l'infini
(sinon copier-coller suffirait)

13. Le socle transverse
Logiciel
Idée
•Travail collaboratif (wiki, tâches, GED...)
•Gestion des sources
•Référentiels d'artefacts
•Suivi des demandes, des exigences, tickets
•Authentification, Habilitations

14. Le travail collaboratif
• Les artefacts normaux d’un
projet de développement ne
sont pas que du source
• Prévoir le stockage et
l’archivage des documents
au même titre que le Java
• Pareil pour les tickets de
bug / incidents / évolutions
• Indispensable : le portail
d’accueil du nouveau
développeur
•Un Wiki, bien entendu

15. Les gestionnaires de sources
Pratiques usuelles Subversion (Apache)
Challengers
Git (git team)
Mercurial (mercurial team)
… Autres DVCS (si plugin dans l’IDE)
Perte de vitesse
CVS (CVS team)
$$$ Commerciaux

16. Retour aux sources
git or not git ? (← insérer son DVCS favori ici)
 environnement distribué, difficultés réseau ?
 beaucoup de branches de développement ?
et beaucoup c'est à partir de 3 branches
 plusieurs tâches de dév en parallèle ?
 est-ce que le Subversion est bien employé et maîtrisé de tous?

17. Le référentiel d'artefacts Maven
• Pour gérer tous les artefacts produits et leurs versions
› C’est aux .jar ce que Subversion est aux .java
• Pour ne pas dépendre d’internet pour compléter son build
• Pour instaurer une gouvernance des dépendances tierces

18. Les référentiels d’artefacts
Pratiques usuelles
Nexus (Sonatype)
Artifactory (JFrog)
Challengers Archiva (Apache)
Perte de vitesse Répertoire de fichiers partagé

19. Modélisation, Conception
Logiciel
Idée

20. Conception et génération de code
•Attention à ne pas jeter le bébé avec l’eau du bain :
•Du tout-UML à l’absence de toute documentation d’architecture
ou conception
•La génération de code devrait faire partie de l’usine
•Le tout-MDA : la fin d’un rêve ?
•Le round-trip engineering complet est difficile à atteindre

21. Poste de développement et IDE
Logiciel
Idée

22. Le poste de développement
C’est :
• L'IDE et ses plugins
• Les outils
• serveur local,
• soapUI,
• SQuirreL,
• etc...
… et un paramétrage partagé
par tous les dév de tout ça
Que l’on doit pouvoir :
• Installer ou télé-distribuer
• Composer avec des
politiques de gestion de
parc bureautique
… et le tout doit fonctionner
dans le train ou en télétravail

23. – Rappel –
Développement ≠ Bureautique

24. Les IDE pour Java
Pratiques usuelles Eclipse (Eclipse.org)
Challengers
NetBeans (Oracle)
IntelliJ IDEA (JetBrains)
Rational Application Developer (IBM)
Perte de vitesse Visual J++ (Microsoft)

25. La construction et l’intégration continue
Logiciel
Idée

26. De JavaC à Maven en passant par Ant
•Ant permet de scripter des constructions complexes
•Les apports majeurs de Maven :
• Convention
• Description au lieu de scripts
• Gestion des dépendances
• Les référentiels d’artefacts
•Souvent très mal maitrisé par les développeurs

27. Les outils de construction pour Java
Pratiques usuelles Maven (Apache)
Challengers
Gradle (Gradleware)
Ant + Ivy (Apache)
Perte de vitesse Ant (Apache)

28. Le serveur d’intégration continue
•Chef d’orchestre de l’usine
•Construire, intégrer, tester, déployer en continu
•Exécute en tâche de fond toutes les actions longues
• Le développeur n’est pas bloqué
• Demande très vite infrastructure puissante

29. Les serveurs de construction continue
Pratiques usuelles Jenkins (CloudBees)
Challengers
Hudson (Oracle/Eclipse)
TeamCity (JetBrains)
Bamboo (Atlassian)
Rational Build Forge (IBM)
Perte de vitesse
CruiseControl (ThoughtWorks)
Continuum (Apache)

30. La qualimétrie
Logiciel
Idée

31. Pourquoi inspecter le code source ?
• Pour surveiller les développeurs ?
• Qui pond le plus de lignes ?
• Qui néglige le formatage ?
• Qui a écrit le plus de tests unitaires ?
• On risque d’améliorer l’indicateur,
et non la qualité intrinsèque
• Ne pas espérer un comportement
(nous sommes une équipe)
mais récompenser autre chose
(statistiques individuelles)

32. Pourquoi inspecter le code source ?
• Pour aider les développeurs à
améliorer la qualité du code ?
• Apprentissage des conventions
• Rattrapage des fautes d’inattention
• Relecture du code automatisée
• Attirer l’attention sur du code louche
• Suggérer où porter l’effort de test

33. Les outils de qualimétrie Java
Pratiques usuelles
Rien
Sonar
Checkstyle
PMD
FindBugs
JU Cobertura, JaCoCo, Emma
Perte de vitesse Ne pas passer par Sonar

34. – Attention –
•Installer ces outils ne suffit pas pour obtenir de la qualité
•Ne pas se contenter des chartes qualité par défaut
• Commencer par un jeu de règle restreint, bien compris de tous

35. … on ne vous a pas pris en traître
•Toute validation doit pouvoir être faite à l'identique :
• dans l'IDE (plugin Eclipse, plugin NetBeans...)
• pour le build (task Ant, plugin Maven, ...)
• dans le serveur de construction continue
• dans la doc (wiki, normes de codage...)
• dans la « definition of done »
• …

36. Automatiser les déploiements
Logiciel
Idée

37. Automatiser les déploiements
•Tâche fastidieuse, répétitive et source d’erreurs
•Pour tester la « déployabilité » dès les premières itérations
•Les scripts de déploiement font partie du livrable
•Permet de déployer en continu par l’intégration continue
•Et donc d’automatiser les tests sur application déployée
•Aller jusqu’aux déploiements périphériques :
•Instances de bases de données et jeux de données de test
•Raccordements réseau, configuration, …

38. Les outils de déploiement J2EE
Pratiques usuelles Scripts maison
Challengers
Maven Cargo (cargo team)
DeployIT (XebiaLabs)
Nolio (Noliosoft)
… Serena, HP…
Perte de vitesse Scripts maison

39. De l’idée au logiciel
Logiciel
Idée

40. Automatiser les tests
•Tests fonctionnels
•Selenium pour applis web
•Tests de performance
•JMeter, TPTP
•« Smoke Tests » : test minimal automatisable
•Au moins ça démarre !
•Certes couteux
•mais une heure de test > plusieurs heures de debug

41. Jusqu’à la production
Logiciel
Idée

42. Rapprocher fabrication et exploitation
•Utiliser les mêmes scripts ou outils de déploiement
•Utiliser un référentiel de livrables commun
•Avec traçabilité et liaison avec éventuelle CMDB
•Tester déployabilité et exploitabilité au plus tôt
•Déploiement et test automatisés en continu
•Permettre aux logs de remonter aux études
•Enseigner aux développeurs ce que sont des logs utiles
•Documentation commune

43. Et le reste, tout le reste…
•Virtualisation de services
•Assistance à relecture de code
•Outillage SGBD
•Profiler
•Analyse de logs
•Obfuscation des classes

44. Comment héberger l’Usine Logicielle

45. L’Usine Logicielle incognito
Si l'usine n'est pas fournie...
...elle risque d'être montée
en douce
sur un poste de dév

46. Une Usine Logicielle, est-ce de la prod ?
Quelle qualité de service puis-je garantir aux projets ?
L’Usine Logicielle à la maison
•Répartir les responsabilités :
• Software Factory Manager
• Cellule architectes / normes
• Equipe projet
•Par exemple :
• Qui crée et configure les jobs
de build ?
• Qui choisit les plugins sur l’IC ?
• Qui maintient les esclaves de
build ?
•On est passé de vi & javac à
une flopée d'outils
•Une Usine Logicielle,
est-ce de la prod ?
•Quelle qualité de service
puis-je garantir aux projets ?
•Quel est mon bugdet ?

47. L’Usine Logicielle in-a-box
•Une «virtual appliance »
autonome contenant toute
l’Usine Logiciellle
•Ou plutôt une usinette…
difficile de tout faire tenir sur un
serveur
•Dédiée projet, à archiver ou
rallumer selon cycle de vie
•Référentiels partagés

48. L’Usine Logicielle dans le cloud
•Infrastructure de qualité, scalable
•Accessibilité (y compris en télétravail)
•Paiement à l'usage
Mais :
•Pas d'outils exotiques
•Juridiction partagée
•Confidentialité des sources ?
•Confidentialité des données de test ?

49. Le métier de Software Factory Manager

50. Assistance au développement…
•Impliqué dans tout le cycle de vie du logiciel
•Mise en place de l'usine Logicielle
•Aide au choix des outils
•Assistance aux utilisateurs / développeurs
•Relation forte entre la fourniture de frameworks ou
stacks d’entreprise et l’outillage qui va avec
•Amélioration continue des outils et pratiques de dév

51. …mais aussi administration système
•Si priorité absolue à « réparer » tout build en échec,
alors l’Usine Logicielle doit tourner avec la même priorité
•Le Software Factory Manager est également Sysadmin :
•Installation et mise à disposition de serveurs,
•Garantie de disponibilité,
•Montage de clusters de build,
•Réplication de référentiels,
•Déploiement en cloud ou hybride
•Donc appliquer les bonnes pratiques « DevOps »

52. Un pour tous ou tous pour un ?
•Pas forcément un plein-temps
•si nombre de projets réduits
•porté par un architecte par
exemple
•Jusqu’à des équipes de
plusieurs dizaines de personnes

53. Et pour les aspirants Artisans du Logiciel
(c.f. http://manifesto.softwarecraftsmanship.org/)
« C’est à la qualité des outils
que l’on reconnait le bon ouvrier »

54. Crédits photo flickr.com/people/…
/wiredforsound23 /pasukaru76
/anemoneprojectors /yuyang226
/dicknella /mrpony
/passer-by /drewmaughan
/rhysasplundh /chiky
Merci !
Questions ?