2. Agenda Principes et enjeux L’intégration continue Les outils disponibles Intégration continue à KLEE Questions / Réponses
3. Introduction Dé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. Enjeux La productivité La qualité logicielle La réactivité L’autonomie La standardisation des règles de développement Détection des erreurs au plus tôt La testabilité et la non régression
4. Qualité logicielle ? Elle est évoquée pendant toute la durée de vie d’un projet PAQ Responsable qualité Qualité technique des développements … Des principes existent depuis très longtemps Conception et ergonomie Développements pilotés par les tests … Souvent négligée au profit de la supposée rentabilité du projet Qui ? Ceux qui conçoivent et programment le logiciel
5. Qualité logicielle / Acteurs Différentes visions de la qualité logicielle Utilisateur final : fonctionnel, ergonomie, fiabilité Développeur : rapidité de développement, conception, lisibilité du code … Exploitant : facilité d’installation et de déploiement Architecte : interopérabilité, portabilité, qualité technique …
6. Qualité logicielle / Caractéristiques Caractéristiques définies par une norme ISO ISO 9126 Software Quality Model http://www.sqa.net/iso9126.html 6 caractéristiques Capacité fonctionnelle Fiabilité Facilité d’utilisation, homogénéité Maintenabilité Rendement / scalabilité Portabilité
7. Coût de la non qualité : Dette technique Deux 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 projets Montée en compétence Corrections, Itérations Conflit, réunions … Dette technique
8. La qualité, à quel prix ? Optimisation des coûts qualité Evaluer le niveau de qualité en fonction du contexte Système de pilotage automatique d’une navette spatiale Application de gestion de demande de logement sociaux ≠
9. Solutions qualité Programmation orientée objet Un rôle et une responsabilité distincte Abstraction des éléments stables Conception par contrat Principe Open / Close … Tests Gestion des sources Standardisation des règles de développement Industrialisation des développements
10. Agenda Principes et enjeux L’intégration continue Les outils disponibles Intégration continue à KLEE Questions / Réponses
11. Historique Principe tiré de l’eXtremeProgramming inventé par Kent Beck, Ward Cunningham et Ron Jeffries Calcul des rémunérations chez Chrysler, Mars 1996 Octobre 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émarche Problématique Comment écrire du code de qualité ? Comment mesurer la qualité ? Comment identifier les actions d’amélioration ? Comment valider ces actions Comment itérer sur ce processus de qualité ? Phase d’intégration d’un projet longue et couteuse Détection tardive des bugs Eviter le syndrome du « Je ne comprends pas, ça marche sur mon poste.» Commits partiels Fichiers de configuration dépendant du poste de travail
13. Principes (1/3) Principes agiles Fabriquer souvent (« build ») Tester souvent Tester les performances souvent Intégrer souvent dans le SI Faire l’intégration de l’application dans son ensemble, code source et ressources continuellement Détecter les problèmes au fil du temps Corriger au plus tôt Automatiser le processus d’intégration
15. Après la mise en place de l’intégration continue Principes (3/3)
16. La chaine d’intégration continue (1/2) Gérer les sources du projet Mettre régulièrement ses sources à jour Mettre à jour ses sources avant commit Commit au moins une fois par jour Ajouter des commentaires lisibles au commit Tagger les versions à chaque livraison Build un projet à chaque changement « Build » ? Compiler Inspecter (revue de code) Tester Déployer Notifier (email, rapport)
19. Processus d’intégration continue (1/3) Automatiser le processus complet en tenant compte des aspects distribués Plateforme de développement Plateforme d’intégration Plateforme d’acceptation …
20. Processus d’intégration continue (2/3) Plateforme de développement « Local build » : construction de l’application sur le poste de travail Compilation 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 sources Référentiel de sources Ensemble des éléments d’un projet Le code doit être compilable Les tests doivent être exécutés avec succès Stratégie de commit Ensemble 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èrement Lancement des tests, calcul de couverture de tests Calcul d’indicateurs (complexité etc…) Production de rapport (tests, qualité …) : page de statuts, envoi par mail Déploiement d’une version régulièrement Par exemple toutes les semaines Objectif : permettre de faire des tests fonctionnels, tests de performance Visibilité pour le chef de projet des avancements Eventuellement packager une livraison finale
22. Les bonnes pratiques Commiter le code régulièrement Commiter du code bon Résoudre les builds ratés rapidement Tous les tests et les rapports d’inspection doivent passer Lancer des builds sur le poste de travail Garder les builds dans le vert tout au long de la journée Eviter de récupérer du mauvais code
23. Agenda Principes et enjeux L’intégration continue Les outils disponibles Intégration continue à KLEE Questions / Réponses
24. Maven Gestion des dépendances pom.xml Gestion de la compilation, du packaging Gestion des rapports Gestion des livraisons des différents livrables
26. Les tests unitaires Fiabilité et maintenabilité Conception : les tests sont écrits avant la méthode testée Assurent la non régression du produit Les outils : JUNIT ou NUNIT Exemple : couverture de code avec Cobertura
27. Les tests de performance Tester la montée en charge d’une application Information présente dans le CCTP JMETER
28. Outil de qualimétrie : Sonar (1/2) Se base sur les normes ISO : donne une vue d’ensemble d’une application Outil Open source orienté décideur Se base sur MAVEN 3 Exemple : 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 indicateurs Vision temporelle de l’évolution d’un projet
30. Une PIC : Jenkins (1/3) La météo du projet Interface graphique évoluée Tout 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 code Destinataire : les développeurs Les outils java Checkstyle Findbugs : detecte un ensemble de bugs référencés PMD/CPD : détection copier/coller, code mort … Compilateur eclipse : warning et erreurs fournies par l’IDE Installation des plugginseclipse sur les postes de travail Les outils .NET Fxcop Stylecop CSC CPD PHP PHPCheckstyle …
34. Agenda Principes et enjeux L’intégration continue Les outils disponibles Intégration continue à KLEE Questions / Réponses
35. Objectifs Dette technique Il vaut mieux rembourser la dette un jour plus tôt que de continuer à payer sans cesse des intérêts Vision technique et classifiée des différents projets Uniformiser les règles et les outils de développement Traiter 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 contributeurs SVN : Subversion lancé en février 2000 ajoutant principalement Les transactions lors des commit Renommage et le déplacement de fichiers (suivant le support des clients svn ) Aucune distinction entre un label, une branche et un répertoire Numéros de révision sont désormais globaux WebDav (répertoire distant avec Commit automatique) TFS : Team Foundation Server by Microsoft Plateforme d’intégration continue comprenant un gestionnaire de sources
37. Choix Klee CruiseControl : projet open source introduit par Martin Fowler Un ordonnanceur Un format XML pour les résultats Support de ANT Page de statuts simple Résultats d ’exécution par outil KLEE : ajouter des fonctionnalité plus proche de l’opérationnel Page de statuts : indicateurs de l’état du projet Répartition des erreurs par axes opérationnels Intégration des outils pour toutes les plateformes
38. La pages des statuts Identifier rapidement l’état du projet Code 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 projet En 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 outils Tous les modules d’une application doivent être audités Un outils = rembourse une partie de la dette Exemple : audit des packages SSIS avec DTEXEC
41. Un Fichier de configuration Un fichier de configuration général : config.xml
42. Revue de code Destinataire : les développeurs Les outils java Checkstyle Findbugs : detecte un ensemble de bugs référencés PMD/CPD : détection copier/coller, code mort … Compilateur eclipse : warning et erreurs fournies par l’IDE Installation des pluggins eclipse sur les postes de travail Les outils .NET Fxcop Stylecop CSC CPD PHP PHPCheckstyle …
43. Le dispatch Répartition des erreurs en 6 catégories opérationnelles (vs iso) Bug : plantage éventuel DeadCode : code non utilisé Perf : performances pouvant être améliorées FatCode : code « sale » (copier/coller …) Doc : code non documenté CodeStyle : style du code non conventionnel
44. Rapport aux développeur Un mail personnalisé est envoyé aux développeurs Corriger efficacement les erreurs du dernier build
45. Perspectives Paralléliser les Builds Générer des rapports Aux développeur et CP Rapports intégrés aux livraisons Intégrer des processus de tests supplémentaires (tests de surfaces …) Fonctionnement en cluster VM CC1 VM CC2 VM CC3 VM CC4 Tableau de bord
46. Agenda Principes et enjeux L’intégration continue Les outils disponibles Intégration continue à KLEE Questions / Réponses
47. Questions ? Retrouvez nous sur le blog technique de Klee http://blog.kleegroup.com/teknics teKnics@kleegroup.com @teKnics_Klee
