L'intégration continue est une pratique en génie logiciel visant à intégrer fréquemment le travail des équipes, permettant de détecter tôt les erreurs grâce à des processus automatisés. Le document présente les enjeux de la qualité logicielle, les caractéristiques de celle-ci, ainsi que divers outils et principes de mise en œuvre de l'intégration continue, tels que l'automatisation des tests et la gestion des sources. Il aborde également des exemples de dettes techniques et les meilleures pratiques pour maintenir la qualité du code tout au long des projets.

1. Prez Flash :: Intégration continueOlivier BOITEL11

2. AgendaPrincipes et enjeuxL’intégration continueLes outils disponiblesIntégration continue à KLEEQuestions / Réponses

3. IntroductionDéfinitionL'intégration continue est un ensemble de pratiques utilisées en génie logiciel. Elles consistent à intégrer fréquemment le travail des membres d’une équipe ou de plusieurs équipes. Chaque intégration est exécutée par un processus automatique (incluant les tests) et permet de détecter les erreurs d’intégration au plus tôt.EnjeuxLa productivité La qualité logicielleLa réactivitéL’autonomieLa standardisation des règles de développement Détection des erreurs au plus tôtLa testabilité et la non régression

4. Qualité logicielle ?Elle est évoquée pendant toute la durée de vie d’un projetPAQResponsable qualitéQualité technique des développements…Des principes existent depuis très longtempsConception et ergonomieDéveloppements pilotés par les tests …Souvent négligée au profit de la supposée rentabilité du projetQui ? Ceux qui conçoivent et programment le logiciel

5. Qualité logicielle / ActeursDifférentes visions de la qualité logicielleUtilisateur final : fonctionnel, ergonomie, fiabilitéDéveloppeur : rapidité de développement, conception, lisibilité du code …Exploitant : facilité d’installation et de déploiementArchitecte : interopérabilité, portabilité, qualité technique …

6. Qualité logicielle / CaractéristiquesCaractéristiques définies par une norme ISOISO 9126 Software Quality Modelhttp://www.sqa.net/iso9126.html6 caractéristiques Capacité fonctionnelleFiabilitéFacilité d’utilisation, homogénéitéMaintenabilitéRendement / scalabilitéPortabilité

7. Coût de la non qualité : Dette techniqueDeux facteurs de coût sur les projets Bugs Fiablilitécapacité à faire évoluer le SI  Maintenabilité2 Exemples de non qualitéBug sur le calcul des arrondis du nombre de trimestres cotisés pour l’assurance vieillesse = un trimestre de trop pour près de 8 millions de salariés (perte de 2,5 milliards d’euros)Crash de la sonde Mars Climate Orbiter après plusieurs mois de voyages (système métrique international pour le logiciel Vs système métrique impérial pour les capteurs)La non qualité consomme une charge conséquente sur les projetsMontée en compétenceCorrections, ItérationsConflit, réunions…Dette technique

8. La qualité, à quel prix ?Optimisation des coûts qualité Evaluer le niveau de qualité en fonction du contexteSystème de pilotage automatique d’une navette spatialeApplication de gestion de demande de logement sociaux≠

9. Solutions qualitéProgrammation orientée objetUn rôle et une responsabilité distincteAbstraction des éléments stablesConception par contratPrincipe Open / Close…TestsGestion des sourcesStandardisation des règles de développementIndustrialisation des développements

10. AgendaPrincipes et enjeuxL’intégration continueLes outils disponiblesIntégration continue à KLEEQuestions / Réponses

11. HistoriquePrincipe tiré de l’eXtremeProgramming inventé par Kent Beck, Ward Cunningham et Ron JeffriesCalcul des rémunérations chez Chrysler, Mars 1996Octobre 1999 avec le livre « ExtremeProgrammingExplained » de Kent Beck.puisque la revue de code est une bonne pratique, elle sera faite en permanence (par un binôme) ;puisque les tests sont utiles, ils seront faits systématiquement avant chaque implantation…Formalisation par Martin Fowler et Kent Beck, 2000

12. La démarcheProblématique Comment écrire du code de qualité ?Comment mesurer la qualité ?Comment identifier les actions d’amélioration ?Comment valider ces actionsComment itérer sur ce processus de qualité ?Phase d’intégration d’un projet longue et couteuseDétection tardive des bugsEviter le syndrome du « Je ne comprends pas, ça marche sur mon poste.»Commits partielsFichiers de configuration dépendant du poste de travail

13. Principes (1/3)Principes agilesFabriquer souvent (« build »)Tester souventTester les performances souventIntégrer souvent dans le SIFaire l’intégration de l’application dans son ensemble, code source et ressources continuellementDétecter les problèmes au fil du temps Corriger au plus tôtAutomatiser le processus d’intégration

14. Principes (2/3)Avant la mise en place de l’intégration continue

15. Après la mise en place de l’intégration continuePrincipes (3/3)

16. La chaine d’intégration continue (1/2)Gérer les sources du projetMettre régulièrement ses sources à jourMettre à jour ses sources avant commitCommit au moins une fois par jourAjouter des commentaires lisibles au commitTagger les versions à chaque livraisonBuild un projet à chaque changement« Build » ?CompilerInspecter (revue de code)TesterDéployerNotifier (email, rapport)

17. La chaine d’intégration continue (2/2)

18. Les différents type de « build »

19. Processus d’intégration continue (1/3)Automatiser le processus complet en tenant compte des aspects distribuésPlateforme de développementPlateforme d’intégrationPlateforme d’acceptation…

20. Processus d’intégration continue (2/3)Plateforme de développement « Local build » : construction de l’application sur le poste de travailCompilation des sources, exécution des tests, inspection de code …Si possible utilisation des mêmes commandes de build que la plateforme d’IC« commit at all time» : à tout moment les développeurs peuvent mettre à jour le référentiel de sourcesRéférentiel de sourcesEnsemble des éléments d’un projetLe code doit être compilableLes tests doivent être exécutés avec succèsStratégie de commitEnsemble fonctionnel cohérent, Pas de commits « haute fréquence »Des commits maîtrisés (hook, passage des outils locaux)

21. Processus d’intégration continue (2/3)Plateforme d’intégration : build automatiséConstruction automatique de l’application régulièrementLancement des tests, calcul de couverture de testsCalcul d’indicateurs (complexité etc…)Production de rapport (tests, qualité …) : page de statuts, envoi par mailDéploiement d’une version régulièrementPar exemple toutes les semainesObjectif : permettre de faire des tests fonctionnels, tests de performanceVisibilité pour le chef de projet des avancementsEventuellement packager une livraison finale

22. Les bonnes pratiquesCommiter le code régulièrementCommiter du code bonRésoudre les builds ratés rapidementTous les tests et les rapports d’inspection doivent passer Lancer des builds sur le poste de travailGarder les builds dans le vert tout au long de la journéeEviter de récupérer du mauvais code

23. AgendaPrincipes et enjeuxL’intégration continueLes outils disponiblesIntégration continue à KLEEQuestions / Réponses

24. MavenGestion des dépendances pom.xmlGestion de la compilation, du packagingGestion des rapportsGestion des livraisons des différents livrables

25. DeploiementMavenExemple de repositoryMavenSonaType / Nexus

26. Les tests unitairesFiabilité et maintenabilitéConception : les tests sont écrits avant la méthode testéeAssurent la non régression du produit Les outils : JUNIT ou NUNITExemple : couverture de code avec Cobertura

27. Les tests de performanceTester la montée en charge d’une applicationInformation présente dans le CCTPJMETER

28. Outil de qualimétrie : Sonar (1/2)Se base sur les normes ISO : donne une vue d’ensemble d’une applicationOutil Open source orienté décideurSe base sur MAVEN 3Exemple : le dashboard pour un projet- Nombre de lignes / de packages / de classes / de méthode : indications du volume du code source.- Complexité : indice de complexité cyclomatique par méthode et par classe.

29. Outil de qualimétrie : Sonar (2/2)Représentation graphique des indicateursVision temporelle de l’évolution d’un projet

30. Une PIC : Jenkins (1/3)La météo du projetInterface graphique évoluéeTout est plugin

31. Une PIC : Jenkins (2/3)Configuration simple d’un projet

32. Une PIC : Jenkins (3/3)Un nombre important de plugins

33. Revue de codeDestinataire : les développeursLes outils javaCheckstyleFindbugs : detecte un ensemble de bugs référencésPMD/CPD : détection copier/coller, code mort …Compilateur eclipse : warning et erreurs fournies par l’IDEInstallation des plugginseclipse sur les postes de travailLes outils .NETFxcopStylecopCSCCPDPHPPHPCheckstyle…

34. AgendaPrincipes et enjeuxL’intégration continueLes outils disponiblesIntégration continue à KLEEQuestions / Réponses

35. ObjectifsDette technique Il vaut mieux rembourser la dette un jour plus tôt que de continuer à payer sans cesse des intérêtsVision technique et classifiée des différents projetsUniformiser les règles et les outils de développementTraiter tous les types de projets (Java, JCMS, .NET, PHP)Former une nouvelle génération d’architectes techniques

36. Gestionnaires de source (1/3)CVS : par Dick Grune en 1986, puis de nombreux contributeursSVN : Subversion lancé en février 2000 ajoutant principalement Les transactions lors des commitRenommage et le déplacement de fichiers (suivant le support des clients svn )Aucune distinction entre un label, une branche et un répertoireNuméros de révision sont désormais globaux WebDav (répertoire distant avec Commit automatique)TFS : Team Foundation Server by MicrosoftPlateforme d’intégration continue comprenant un gestionnaire de sources

37. Choix KleeCruiseControl : projet open source introduit par Martin FowlerUn ordonnanceur Un format XML pour les résultatsSupport de ANTPage de statuts simpleRésultats d ’exécution par outil KLEE : ajouter des fonctionnalité plus proche de l’opérationnelPage de statuts : indicateurs de l’état du projetRépartition des erreurs par axes opérationnelsIntégration des outils pour toutes les plateformes

38. La pages des statuts Identifier rapidement l’état du projetCode couleur simple : feux de signalisationÉcran d’accueil de CruiseControl optimisé par KLEE afin de proposer un tableau de bord opérationnel aux développeurs et aux chefs de projets

39. Un script de build (1/2)Un script par projetEn java : tâche ANT (générée par Maven 3)En .NET : tâche NANT

40. Un script de build (2/2)Un script de compilation général + un script cruisecontrol de passage des outilsTous les modules d’une application doivent être auditésUn outils = rembourse une partie de la detteExemple : audit des packages SSIS avec DTEXEC

41. Un Fichier de configurationUn fichier de configuration général : config.xml

42. Revue de codeDestinataire : les développeursLes outils javaCheckstyle Findbugs : detecte un ensemble de bugs référencésPMD/CPD : détection copier/coller, code mort …Compilateur eclipse : warning et erreurs fournies par l’IDEInstallation des pluggins eclipse sur les postes de travailLes outils .NETFxcopStylecopCSCCPDPHPPHPCheckstyle…

43. Le dispatchRépartition des erreurs en 6 catégories opérationnelles (vs iso)Bug : plantage éventuelDeadCode : code non utiliséPerf : performances pouvant être amélioréesFatCode : code « sale » (copier/coller …)Doc : code non documentéCodeStyle : style du code non conventionnel

44. Rapport aux développeurUn mail personnalisé est envoyé aux développeursCorriger efficacement les erreurs du dernier build

45. PerspectivesParalléliser les BuildsGénérer des rapportsAux développeur et CPRapports intégrés aux livraisons Intégrer des processus de tests supplémentaires (tests de surfaces …)Fonctionnement en clusterVM CC1VM CC2VM CC3VM CC4Tableau de bord

46. AgendaPrincipes et enjeuxL’intégration continueLes outils disponiblesIntégration continue à KLEEQuestions / Réponses

47. Questions ?Retrouvez nous sur le blog technique de Kleehttp://blog.kleegroup.com/teknicsteKnics@kleegroup.com@teKnics_Klee