Intégration continue

5 393 vues

Publié le

Publié dans : Technologie, Business
0 commentaire
4 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
5 393
Sur SlideShare
0
Issues des intégrations
0
Intégrations
149
Actions
Partages
0
Téléchargements
245
Commentaires
0
J’aime
4
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Intégration continue

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

×