Publicité
Publicité

Contenu connexe

Publicité
Publicité

Usine Logicielle 2013

  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 ?
Publicité