forges logicielles SCM, Build et intégration continue, colonne vertébrale du processus d'industrialisation de l'ingénierie logicielle

Transcription

1 forges logicielles SCM, Build et intégration continue, colonne vertébrale du processus d'industrialisation de l'ingénierie logicielle Philippe ENSARGUET CTO / Factory Skills Center Manager philippe.ensarguet@orange-ftgroup.com

2 agenda «La différence entre un artisan et un industriel, c est sa capacité à reproduire certaines phases de sa production!». c est dans ce contexte que l intégration continue entre en jeu comme outils d automatisation de tâches (compilation, build, test, intégration, déploiement, mesure de la qualité, release, ) au cœur de la production logicielle ou plus largement dans une stratégie de forge logicielle. après avoir présenté les tenants et aboutissants du Build et de l'intégration continue, cette session propose d'aborder les meilleures pratiques à privilégier à partir d'un exemple concret et de retours de nos expériences. 2

3 et Orange Business Services Orange Business Services Global Services IT Solutions & Services activity operator and B2B integrator of communications solutions IT solutions, Unified Communications & Collaboration and Customer Contact solutions operator and B2B integrator of IT solutions design & integrate disruptive IT convergence solutions mission Orange Business Services provides communications services to companies of all sizes in France and to multinationals throughout the world transform, build and operate worldwide infrastructure and business solutions your new trusted partner for disruptive IT solutions specify, design, integrate and optimize focused enterprise application & system solutions worldwide Key facts 7559 M in turnover in million business clients, SMBs and companies in France employees France: 899 M in turnover for services in 2009 (+4% YoY) France: 6th SSII in people certified in Project & Program Management In 2010, 50 new employees were certified PMI, 250 for ITIL in France and our profressionalisation path for Serivces was completed by more than 200 team members 66% of our activity is carried out on a fixed-fee basis CMMI & ISO certified 1400 specialised engineers 3

4 4

5 build ou construction du logiciel pas de définition (totalement) précise! le build peut aller de la compilation, incrémentale, à la génération d un package en passant par la génération de fichiers de source, le lancement de tests (unitaires, d intégration ), l analyse du code source, la génération d un site web et de rapports d une certaine manière, le build englobe l ensemble des actions souhaitées prenant en entrée des fichiers sources pour produire un résultat souhaité. généralement, nous attendons d un outil de build qu il puisse automatiser et optimiser ces actions. 5

6 la problématique du build reproductibilité dans le temps et dans l espace dans l espace pic les builds sur les postes p0, p1, pj, pic doivent être identiques par exemple, il faut pouvoir reproduire le build sur l ensemble des postes de l équipe, du serveur d intégration continue pj p1 p0 t0 t1 ti dans le temps les builds aux temps t0, t1, ti doivent être identiques par exemple, il faut pouvoir à tout moment reproduire le build d une version taggée Il faut aussi définir ce que veut dire identique 6

7 la problématique du build de nombreuses influences Le build est une opération qui paraît simple, mais dans les faits c est une problématique compliquée et nous ne disposons toujours pas de solution qui permette d assurer cela Variables d environnement Outils de build options de compilation compilateur OS Dépendances ressources code source Fichiers sources Facteurs humains Plateforme d exécution Repositories maven Base de données xml schemas wsdl Ressources externes build artefacts 7

8 Maven, le fil rouge permettre aux personnes de se concentrer sur leur tâche principale plutôt que de passer du temps à régler des problèmes annexes liés au build «standardiser» la manière de travailler ce qui facilite la réutilisation et le passage d'un projet à un autre améliorer la qualité du code par une approche d'intégration continue 8

9 Maven, le fil rouge Maven est un outil de gestion de projet qui en tant que tel nous assiste dans de nombreuses tâches build, tests, intégration continue, documentation, reporting, gestion des sources, gestion de l équipe, diffusion, convention plutôt que configuration règle du 80/20 les opérations de builds suivent un pattern uniformité et reproductibilité du processus extension par plug-ins 9

10 à retenir! Pas d intégration continue sans stratégie de build totalement opérationnelle 10

11 l intégration continue l'intégration continue est un processus d'automatisation des tâches récurrentes liées à l'environnement de développement, telles que la construction, le déploiement, l'exécution des tests unitaires et d'intégration, etc. l'intérêt de cette automatisation réside dans sa fréquence d'exécution, qui doit au moins être quotidienne. on dispose ainsi régulièrement de nouvelles versions d'une application et de l'état actuel du projet. 11

12 intégration Continue la problématique Module 1 Module 2 Module i Développement Intégration Source: Les 5% de bugs découverts après la release représentent 95% des coûts de correction 12

13 Module 1 Module 2 Module i intégration Continue la problématique Développement Intégration Les 5% de bugs découverts après la release représentent 95% des coûts de correction Détecter au plus tôt les problèmes pour les corriger au plus tôt Intégration Continue Intégration Intégration Intégration Intégration Intégration Intégration Module1 Module2 Modulei 13

14 intégration continue un processus d orchestration l'intégration continue ne se résume pas seulement à la simple mise en œuvre d'un outil permettant d'automatiser la compilation. il s'agit davantage d'un processus qui va orchestrer le quotidien des développeurs autours de trois composants : un outil de construction automatisée tel qu'ant ou Maven, permettant aussi bien au développeur qu'à l'outil d'intégration continue de construire tout ou partie du système. un unique système de gestion de sources, tel que CVS ou Subversion (ou git), contenant les sources et l'historique des modifications apportées par les développeurs sur le système. A chaque mise à jour, le serveur d'intégration continue de charger les modifications et exécute la construction complète du système. un serveur d'intégration continue, tels que Jenkins (Hudson), Bamboo, Continuum ou Cruise Control. Son rôle est de détecter les mises à jour sur le système de gestion de sources, d'exécuter le cas échéant la construction du système et de notifier l'équipe de développement du résultat. 14

15 le processus d intégration continue 1 Développement, correction d une fonctionnalité Spécifications Implémentation de la fonctionnalité ou correction et des tests unitaires 4 Historisation et publication des résultats Compilation privée du module ou projet Enregistrement dans le SCM 2 Détection du besoin d intégration Enregistrement des résultats Génération des rapports Notifications des résultats Publication de l artéfact 3 Intégration Évènements envoyés par le SCM Scrutation du SCM Périodique, manuelle Mise à jour depuis le SCM Compilation du projet Tests unitaires et d intégration Analyses de la qualité de code 15

16 Intégration continue l outillage Production de code Accueil d un nouveau développeur Enregistrement des modifications Gestion de dépendances Compilations privées Gestion de configuration Outil de compilation pom.xml Détection du besoin d intégration Chargement de modifications Intégration continue Compilation, tests Analyses de code 16

17 détail du processus * Notification s Évènements de déclenchement Appel d actions Rapports Artéfacts Notifications comment : SMTP, Jabber, Communicator, RSS, etc. Intervention Script qui :(Bat, liste humaine de Shell) destinataires, depuis plusieurs l'outil listes d'icpossibles; le(s) dernier(s) comiters quand : Systématiquement après chaque build, Conditionnel (échec, qualité de code ) Périodique Rapports Script Ant (CRON) Détection analyse de static modifications du code (PMD, dans checkstyle, SCM Findbugs), (polling) Script rapport Maven de tests 1 Par dépendance (tests unitaires, couverture ), suivi des modifications du SCM Publication Script Maven historique d'une 2 des résultats API (Web de builds, Service, Analyse JMS, évoluée Jabber...) des résultats de builds Modifications historique des dans métriques, SCM (notification) Dashboard, etc. Artefacts lien vers le résultat du build (JAR, site web ) 17

18 intégration continue critères de choix fonctionnels Notification s Mails, Jabber, Lava lamps Évènements de déclenchement Appel d actions Rapports Tests unitaires, qualité de code : PMD, Findbugs Périodique, manuel, détection de modifications dans le SCM Outils de build : Ant, Maven, Shell Artéfacts Jar, War Détection du besoin d intégration Intégration Historisation et publication des résultats 18

19 intégration continue critères de choix techniques exigences techniques Environnements d exécution : Windows, Linux Mode d exécution : application WEB, service Conteneurs WEB supportés : Tomcat, Websphere Tout autre critère lié à l environnement technique où sera utilisé le serveur d intégration continue. exigences de contraintes opérationnelles Sécurité : authentification, contrôle d accès Administration : installation, configuration, exploitation Utilisation : ergonomie, prise en main Fournisseur : coût, licence, maturité 19

20 industrialisation des développements vers un workflow checkout, update Intégration Continue construit déploie teste analyse Artéfacts SCM Outils de build développe teste compile Rapports Notifications checkout, commit, update, merge Développeur informe 20

21 pratiques à privilégier et anti-patterns détecter et résoudre les problèmes au plus tôt commiter du code qui marche fréquemment exécuter des builds privés développer de petites tâches commenter chaque commit valider le build par des tests (unitaires et fonctionnels) qui passent à 100% pas de test = pas d erreur, les tests doivent être pertinents prendre en compte la couverture de test intégrer après chaque commit temps de build < 10 min distinguer les différents tests exécuter une intégration complète au moins une fois par jour corriger les échecs de builds immédiatement! Stopper les commits! adapter le système de notification à l équipe 21

22 pratiques à privilégier et anti-patterns reproduire le build dans le temps et l espace le build doit être automatisé au maximum l environnement de build doit être propre privilégier le checkout, au moins pour l intégration complète quotidienne nettoyer le dépôt local de Maven selon les cas, intégrer sur différentes plateformes dans certains cas, l utilisation d un miroir du SCM peut-être utile anti-patterns : 22 absence de référentiel de sources intégration sur le poste de développement utilisation de scripts de build différents entre le développement et l intégration

23 pratiques à privilégier et anti-patterns l amélioration de la qualité de code l analyse de code est à mettre en place dès le début du projet se fixer des objectifs raisonnables automatiser les tâches de relecture anti-patterns : les objectifs trop ambitieux peuvent décourager sélectionner les règles prévoir du temps dédier à l amélioration de la qualité de code sentiment de flicage : les métriques ne sont pas une note! il est très simple de contourner les outils d analyse excès de confiance de bonnes métriques n impliquent pas que l application ne comporte pas de bogues, ou que de mauvaises pratiques n ont pas été implémentées. 23

24 le bénéfice, la réduction des risques la gestion du temps contrairement à une intégration programmée en vue d'une livraison, et dont la durée est difficilement prévisible, l'intégration continue est fondue dans la phase de développement. il n'y a plus de longues phases d'intégration, à tout moment l'état du système est connu. 24

25 le bénéfice, la réduction des risques fiabilité un projet testé tout au long de son développement a toutes les chances de contenir moins de bogues. selon la pertinence des jeux de tests, davantage de bogues sont détectés au plus tôt, donc plus facilement identifiables et rapidement corrigés puisqu'ils sont liés aux récentes modifications le SCM est utilisé comme simple support d'archivage. Le projet n'est pas dans un état stable et ceci est la dernière préoccupation des développeurs. les échecs sont immédiatement corrigés, commits fréquents. 25

26 le bénéfice, la réduction des risques la qualité de code les bogues ont la fâcheuse tendance à se cumuler. Plus il y en a, plus il est difficile de supprimer chacun d'entre eux. Ceci est en partie dû aux interactions entres les bogues, où un échec est le résultat de plusieurs erreurs, rendant chaque erreur plus difficile à trouver. > l'effet psychologique sur le développeur n'est pas négligeable, d'autant plus si l'on se trouve dans un contexte d'urgence. - la qualité des corrections est bien souvent délaissée au profit de la rapidité de mise en œuvre. - pour éviter de telles situations, dans une démarche d'intégration continue, LA tâche prioritaire lorsqu'un bogue est découvert est de le corriger. 26

27 le bénéfice, la réduction des risques réactivité une version est toujours disponible, permettant ainsi les fréquents déploiements et mises à jour. l'intégration continue se prête alors parfaitement au cycle de développement collaboratif : les retours clients sur les fonctionnalités du système ainsi que leurs prises en comptes sont plus rapides. 27

28 mais aussi l amélioration de la productivité des développeurs compilation tests unitaires packaging 1' 2' 4' x 20 x 20 x 15 tests d'intégration site web 8' 10' x 15 x 2 Intégration Continue x' x compilation 2' x compilation 2' x compilation 2' x tests unitaires 4' x tests unitaires 4' x tests unitaires 4' x 10 5 packaging 1' x 15 packaging 1' x 13 packaging 1' x 15 tests d'intégration 8' x 02 tests d'intégration 8' x 24 tests d'intégration 8' x 0 site web 10' x 02 site web 10' x 1 site web 10' x 0 x' x x' x x' x 28

29 stratégie de tests une couverture exhaustive 29

30 au cœur de la stratégie de tests le coût informatique global d une anomalie détectée en production est : 2 fois supérieur au coût d une anomalie détectée en recette 15 fois supérieur au coût d une anomalie détectée en conception malgré les derniers progrès, >50% des projets ne tiennent pas leurs objectifs de périmètre, de coût, de qualité ou de délai le processus de test global peut représenter jusqu à 30 à 40% du budget projet la maîtrise du processus de tests garantit la maîtrise des risques, des coûts, de la qualité et des délais 30

31 le coût (caché) de la mise en place d une industrialisation des développements et de la mesure de la qualité Temps Complexité Coût SCM Build Repo IC Tableau de bord Tests Unitaires Tests fonctionnelles Tests IHM outillage déployé 31

32 stratégie de tests de nombreux acteurs Production MOA+MOE MOA MOE 32

33 stratégie de tests du code pour protéger le code mais aussi le développeur! c est la concrétisation du contrat qui lie le développeur à la spécification tests unitaires procédure permettant de s'assurer du bon fonctionnement d'une portion (une «unité») de programme (en Java, unité = méthode). obtenir la couverture de code la plus importante bonnes pratiques : reproduire chaque anomalie avec un test privilégier le développement dirigé par les tests (TDD) au final : automatiser les exécutions et maîtriser les régressions la notion de test unitaire permet de concrétiser un test technique sur un «bout» de code, mais en fonction de la catégorisation du composant l utilisation de bouchons devient indispensable pour tester aux «frontières» 33

34 stratégie de tests des règles métiers pour s assurer que l application se comporte comme elle le devrait tests fonctionnels des scénarios illustrent les cas d utilisation validés par la MOA rédigés en concertation par la MOA et la MOE avec un langage commun implémentés par les équipes de développement le développement dirigé par le comportement (BDD) permet de suivre l avancement les tests en échecs correspondent aux fonctionnalités manquantes ou ayant évoluées au final : automatiser les exécutions et valider le comportement 34

35 stratégie de tests des IHM pour valider le bon fonctionnement d une interface graphique peuvent être détournés : pour valider le comportement d une application en amont d un refactoring aveu d une mauvaise conception initiale pour reproduire un bug tests fonctionnels reproduction d enchaînements d actions sur une interface. les règles métiers doivent idéalement être bouchonnées approche différente de TDD et BDD : le test vient valider le fonctionnement d une interface existante les tests fonctionnels sur les IHM ne sont pas adaptés aux interfaces évoluant fréquemment au final : à utiliser avec parcimonie en fonction des besoins 35

36 stratégie de tests d intégration pour valider l interaction entre plusieurs composants d un système tests d intégrations peuvent aller du simple test d interaction entre deux classes jusqu au test d interaction entre deux systèmes (via Web Services, entre le programme et sa base de données, etc.) pour ne tester que les composants d un sous-système, il peut être nécessaire de «bouchonner» les sous-systèmes en dépendances. définition de contrats d interface bonne pratique : mise en place de l intégration continue au final : automatiser l exécution et détecter les problèmes au plus tôt l importance de la constance du nommage des objets devient critique dans la stratégie de test pour respecter le découpage et la catégorisation des classes et/ou composants 36

37 industrialisation des développements outillage de tests tests unitaires : framework de tests : JUnit, TestNG bouchons : jmock, Mockito, EasyMock tests d intégration : gestion des jeux de données de tests en base : DBUnit tests de charges et performances : JMeter bouchons : à développer selon les besoins à partir des interfaces définies tests fonctionnels : JBehave, Greenpepper tests d IHM : Selenium ces outils s intègrent dans l IDE Eclipse, l outil de build maven et le serveur d intégration continue Hudson. Ils sont donc compatibles avec les pratiques de TDD, BDD et d intégration continue. 38

38 industrialisation des développements outillage de qualité de code un outillage tout au long du cycle de vie du projet sur le poste de développement dans le processus de construction dans le processus d intégration continue différents types d outils qualité du code produit : Checkstyle / PMD / Findbugs analyse statique de code. possibilité de configurer ou créer de nouvelle règles couverture de tests unitaires : Cobertura supervision des métriques, analyses quantitatives et aide à l amélioration du code : Sonar différents types de validation mais toujours en alignement avec un manuel de codage 39

39 industrialisation des développements outillage de qualité de code Sonar tableau de bord de suivi de qualité de code unique interface de gestion des règles de codage activation / désactivation des règles CheckStyle / PMD / Findbugs Eclipse et Hudson utilisent les règles de Sonar pour dans une optique de forge logicielle dans un environnement Java, l utilisation de Sonar comme gestionnaire de référentiels des règles permet une centralisation et un partage des sources de validation 40

40 et pour étendre le périmètre automatisation du lien Build Run - gestion de plate-forme sous forme de dépendances - allocation/désallocation de ressources à la volée - préfiguration de plates-formes cibles métrologie en continue - constater «en continue» une dégradation ou amélioration de performance - nécessite un lien et une automatisation Build Run effective - définition d une stratégie de mesure de la performance maîtrise de l application de la politique Open Source et du respect de l utilisation des contrats de licence associés - nécessite un outillage dédié - très peu de solutions (réellement) opérationnelles Virtualisation (masterisation) du poste de développement 41

41 conclusion un pré-requis à ne pas perdre de vue : - pas d intégration continue sans professionnalisation du Build - pas de Build sans professionnalisation de la gestion du code une chaîne d outillage «abordable» Open Source Compétences mais un outillage dont il est INDISPENSABLE d accompagner et soutenir le déploiement (instruction, coaching, ) une forge est une ressource d entreprise, c est un projet porté par la DSI comme peut l être un projet d annuaire ou de messagerie. 42 ne pas oublier les process et l outillage Back-Office du provisionning des ressources nécessaires à la création de l environnement

42 merci