Etude de l utilisation de l intégration continue en entreprise

Transcription

1 Projet de Recherche et Innovation 5ème année Filière logicielle Etude de l utilisation de l intégration continue en entreprise Auteur : Ronan Presle Tuteur encadrant : Thierry Blanc 13 mai 2015

2 1 Licence 1.1 Français Ce document est publié sous licence Creative Commons CC-BY. Vous êtes autorisé à : Partager : copier, distribuer et communiquer le matériel par tous moyens et sous tout format Adapter : remixer, transformer et créer à partir du matériel Cela pour toute utilisation, y compris commerciale. L offrant ne peut retirer les autorisations concédées par la licence tant que vous appliquez les termes de cette licence. Selon les conditions suivantes : Attribution : vous devez indiquer la paternité de ce matériel de manière appropriée, fournir un lien vers la licence appliquée et indiquer si des changements ont été fait sur l œuvre. Vous devez le faire de manière suffisamment explicite et cela sans suggérer que l auteur soutient les changements apportés. Aucune restriction supplémentaire : Vous n êtes pas autorisé à appliquer des conditions légales ou des mesures techniques qui restreindraient légalement autrui à utiliser l œuvre dans les conditions décrites par la licence. 1.2 English This document is published under the terms of Creative Commons CC-BY. You are free to: Share : copy and redistribute the material in any medium or format Adapt : remix, transform, and build upon the material for any purpose, even commercially. The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution : You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. No additional restrictions : You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits. 1

3 Résumé Le présent document constitue la partie théorique du Projet de Recherche et d Innovation que je réalise au cours de mes quatrième et cinquième années à l Exia.CESI. Il concerne l utilisation des processus d intégration continue en entreprise. Ce document est constitué d un état de l art présentant les processus, leur fonctionnement et leurs objectifs et d une étude de l utilisation de ces processus en entreprise. Enfin, je propose une solution simple et répondant aux problématiques exprimées par les sociétés afin qu elles puissent mettre en place les processus d intégration continue. L intégration est le processus de partage de code entre développeurs sur un dépôt commun. A chaque intégration, les codes sont réunis et échangés entre eux. L intégration continue est une pratique de vérification du code à chacune de ses intégrations ayant pour but d éviter la régression du code ou l apparition d une anomalie au sein de celui-ci. Le code est vérifié par un système automatisé de construction qui va valider son bon fonctionnement et sa bonne intégration au reste de l application existante sur le dépôt. Cela permet de s assurer que le code peut être compilé sans erreur après chaque partage. L utilisation de tests permet également d assurer le bon fonctionnement de l application, ils sont généralement exécutés lors de la construction. Durant ce projet, j ai mené une étude auprès d entreprises de type éditeur de logiciel et société de services. Les résultats m ont prouvé que nombre d entre elles n utilisent pas de processus d intégration continue. Les raisons sont diverses mais on retrouve régulièrement des problématiques de complexité, de coût d installation et de méconnaissance de ces processus. À travers les recherches que j ai menées et ma propre expérience de l intégration continue, je suis conscient de cette complexité de mise en place. Cependant, certaines technologies nous permettent aujourd hui de simplifier cette mise en place. De nombreux outils de qualité sont également disponibles sous forme de logiciels libres. Ce Projet de Recherche et d Innovation va donc avoir pour but de résoudre les problèmes qui empêchent les entreprises d utiliser des processus d intégration continue. La finalité de ce projet est donc de présenter l intégration continue comme un outil capital pour les développements d applications. A titre de solution, un ensemble d outils permettant la mise en place de processus d intégration continue dans les entreprises n en possédant pas sera 2

4 mis à disposition de celles-ci. Elle sera proposée sous la forme d un ensemble de conteneurs Docker. Elle prendra en compte les contraintes relevées par l étude et sera distribuée sur un site internet avec une documentation facilitant son utilisation. Abstract This document is the theoretical part of the research and innovation project that is realized during fourth and fifth year in Exia.CESI. It deals with the use of continuous integration in companies. The first part of this document is composed by a presentation of the project, how I have chosen my subject and which technology will be studied, a presentation of continuous integration, how it works and what its goals are. Then, I will present the result of the survey, the tools that will be used in the final solution and the solution itself. Integration is the process that every developer faces everyday to share his code on a central repository. Continuous integration is a practice coming from Extreme programming that assure that the application present on the repository is fully functional. The source code is verified regularly by an automated system. Once the compilation is checked, tests will be run to ensure that no regression has been inserted in the code. In this project, I have lead a survey in order to dicover why continuous integration was not used averywhere. The results proved that companies don t know about continuous integration or think that it is complex and long to set up and too expensive. Based on my personnal experience, I knew that it was not so complicated or expensive. A lot of technologies can help them to set up a completed set of tools and use continuous integration everyday. Nowadays, many tools are available as free softwares. This project aims to resolve those problems that prevent companies from using continuous integration. At the end of the project, companies will know that continuous integration is essential to improve performance in a development project. I will provide a solution that will contain several tools to use continuous integration processes. This solution will be based on given problems and will be easily deployed. 3

5 Remerciements Je souhaite tout d abord remercier Clément David, Pierrick Knecht, Pierre Lallement, membres de l équipe TotoAndCo et Romain Girard pour leur aide sur ce projet, ainsi que pour les autres projets que nous avons réalisés ensemble en utilisant des techniques et outils inconnus qui nous ont beaucoup appris. Je remercie Thierry Blanc et Stéphane Mahaud, respectivement tuteur et directeur de l Exia.CESI de Lyon, pour l aide qu ils m ont apportée lors de la réalisation de ce projet. Je remercie également Majid El Idrissi et Vincent Levorato, tuteurs à l Exia.CESI d Orléans pour toute l aide et les connaissances qu ils m ont apportées tout au long de ma formation. Ils sont ceux qui m ont communiqué cette envie d approfondir mes compétences techniques. Je remercie ensuite Philippe Charrière, Directeur de Propositions dans l entreprise SQLi à Lyon avec qui j ai réalisé un stage de trois mois en projet de Recherche et Développement. Il m a rappelé à quel point il est important de rester en veille afin de pouvoir s adapter à un monde informatique en permanente évolution. Je remercie également Antoine Vianey, maître de stage de quatrième année au sein d Astek. Il m a permis de découvrir l intégration continue et les avantages que cela présente. Je remercie Zenika et tous les collaborateurs qui y travaillent pour les nombreuses conversations techniques, les échanges de connaissances et la passion qu ils partagent tous. Je remercie Lou Rochard pour son aide et son soutien pendant toutes ces années. 4

6 Table des matières 1 Introduction 7 2 Etat de l art L étude Retour en arrière Les raisons de ce sujet Les langages Le C Le C Le Java Le C# Choix du langage L intégration Continue Définition et objectifs Composant de l IC Fonctionnement simple Réduction des risques Les tests Catégorie de tests Etude Questionnaire Outils Automatisation avec Maven Versionning avec Git Serveur d intégration avec Jenkins Couverture de test avec Jacoco (Emma) Qualité avec SonarQube Solution Docker Docker-Compose Format de la solution

7 4 Conclusion 45 6

8 1 Introduction Le développement logiciel est un domaine de l informatique qui est en permanente évolution depuis l émergence de l informatique dans les années Le cœur du développement logiciel est l étude, la conception, la création, le maintien de logiciels. Les phases de développement d un logiciel sont souvent réalisées en équipe. Certaines problématiques apparaissent donc en ce qui concerne le partage du code réalisé. Ce code développé sur les postes individuels doit être regroupé et il est nécessaire de vérifier le fonctionnement de l application après l assemblage du code. Pour pouvoir vérifier que l ensemble fonctionne correctement, il faudrait pouvoir réaliser une compilation avec les nouvelles sources. Ce premier traitement permet de vérifier qu il n y a pas d erreur syntaxique dans le code, mais ne permet pas de détecter les erreurs de logique qui peuvent apparaitre lorsque plusieurs personnes travaillent sur le même projet. Pour cela la construction qui devra être automatisée doit également exécuter des tests rédigés par les développeurs afin de vérifier qu il n y a eu aucune régression sur l ancien code lors de la modification. Tout ceci fait partie de l intégration continue. Ces processus permettent l amélioration de la qualité des développements mais ne sont pas présents dans toutes les entreprises. Pourquoi les éditeurs de logiciels n utilisent pas ces outils qui pourraient augmenter la qualité de leurs produits? Dans ce document, je vais d abord présenter les processus principaux de l intégration continue et en présenter l intérêt pour une entreprise éditrice de logiciels. Je proposerai ensuite une solution de mise en place d outils permettant la mise en place de processus d intégraton continue et répondant aux problématiques émises par des entreprises. Cette solution sera disponible sur mon site professionnel et publiée sous licence libre. 7

9 2 Etat de l art L intégration continue (IC) n est pas une technique récente. Cela fait déjà plusieurs années que les entreprises l utilisent afin d améliorer les projets de développement logiciel. Nous allons voir ce qu est l intégration continue et quels sont les processus qui la constituent. Ceci nous permettra d avoir les connaissances nécessaires pour aider les entreprises cibles à l utiliser. 2.1 L étude Le développement logiciel est un domaine très vaste. Il concerne énormément de sujets différents et la manière de le pratiquer est différente dans chaque lieu. Le nombre de langages existants donne un exemple de la variété de cadres du développement logiciel. L intégration continue repose sur ce domaine et possède donc tout autant de diversité notamment au niveau des outils qui la constituent. Afin de définir des limites à notre projet, nous allons tout d abord revenir sur l évolution du développement logiciel et sur les langages principaux utilisés aujourd hui Retour en arrière Ada Lovelace est considérée par beaucoup comme étant la première personne à avoir conçu un programme informatique. À travers un certain nombre de notes, elle décrit les différents états d une machine afin de réaliser un traitement logique. Elle fut la première à émettre l idée d une machine capable de manipuler des symboles en accord avec des règles et à penser que les nombres pourraient représenter autre chose que des quantités. Cela marque la transition entre le calcul mathématique et le calcul logique qu utilisent les ordinateurs actuels. En 1843, elle publia une traduction d un article de mathématiques français grâce au Moteur Analytique[36]. Dans les années 1940 apparaissent les premiers ordinateurs électriques, qui se rapprochent de ceux que nous connaissons aujourd hui. Mais leur utilisation est complexe. Le développement sur ces plates-formes doit être effectué en langage assembleur et même parfois en langage machine afin d optimiser l utilisation de la mémoire et des capacités de calcul de l ordinateur. Ceci amenait une complexité intellectuelle très importante et des causes d erreurs récurrentes. 8

10 Pour répondre à cette problématique, plusieurs langages sont mis au point : le Plankalkül, qui, à cause de la guerre puis de l Allemagne divisée, ne s est développé qu en 1998[15], le langage de l ENIAC qui est un langage spécifiquement conçu pour un ordinateur utilisé jusqu en 1955[23] et le jeu d instructions de la SSEM, première machine à architecture de Von Neumann[37]. Dans les années 1950, plusieurs langages importants ont été conçus, et sont encore utilisés dans une forme très peu modifiée : le FORTRAN, le LISP et le COBOL, basés respectivement sur la traduction de formules, le traitement des listes et la programmation d applications de gestion. C est également à cette époque qu est apparue la notion de langage orienté vers l algorithme avec l AL- GOL (Algorithmic Oriented Language)[1]. Ce langage apporte à la programmation informatique les notions de blocs logiques imbriqués et celle de la portée des variables. Ces concepts seront réutilisés dans la majorité des langages qui seront conçus par la suite. Certaines fonctionnalités de ce langage, trop complexes à mettre en place, le rendent impopulaire auprès des programmeurs. L un d entre eux créera une nouvelle version plus simple de ce langage : le Pascal. Entre 1967 et la fin des années 1970 est apparu un grand nombre de langages, et la conception des paradigmes principaux de la programmation. Un paradigme est une manière dont le langage va répondre à un problème posé. Il définit la manière dont l utilisateur du code de ce langage va voir et concevoir le programme afin de résoudre un problème. Un langage s appuie généralement sur plusieurs paradigmes afin de répondre à un nombre de problématiques plus grand. Aucun paradigme n est plus puissant qu un autre dans tous les domaines. Ils ont chacun leurs avantages et inconvénients[40]. La programmation déclarative dans laquelle se caractérise par la notion de fonction comme entité de base, manipulable au même titre que des variables et qui est utilisable dans d autres fonctions. La programmation orientée objets étend la programmation déclarative avec une abstraction supplémentaire, la notion d état, qui est très importante, le polymorphisme et l héritage. Elle permet d augmenter la modularité d un programme. La programmation multi-agents se base sur un ensemble d activités indépendantes qui vont collaborer afin d atteindre l objectif commun[40]. C est également sur cette période qu est apparu le langage C utilisé pour la programmation système d Unix. Nous reviendrons sur ce langage plus tard. Durant les années 1980, les chercheurs vont principalement se concentrer sur 9

11 Figure 1 Détails des principaux paradigmes de programmation. Peter Van Roy [40] l amélioration des langages existants. Ainsi, le C++ va être conçu en reprenant comme base le C et en y ajoutant, entre autres, le paradigme de la programmation orientée objets. Le langage Ada va être normalisé par les États-Unis. Les performances vont également être augmentées avec l apparition des modules, qui sont des unités de programmation entièrement paramétrables et donc facilement utilisables pour différents buts. Depuis les années 1990, les langages apparus n ont pas apporté de grandes 10

12 nouveautés, mais les concepts de base ont été approfondis pour améliorer la productivité des développeurs et la fiabilité des applications réalisées. C est dans cette période que sont conçus le Java de Sun Microsystem et le C# de Microsoft, tous deux orientés objets. On voit également se développer Internet et donc les langages gravitant autour de cette technologie comme le PHP, le Javascript et le Python. De nombreuses pratiques sont venues s ajouter aux projets de développement logiciels afin de permettre l amélioration de la productivité des développeurs. Très rapidement, le partage de code est devenu un enjeu majeur lorsque la taille des équipes de développement augmente. Puis, il a fallu s assurer que le travail collaboratif n empêche pas l avance globale du projet en mettant en place des tests automatisés. L augmentation de la taille des applications a vu se développer le nombre de dépendances ce qui a mené à la création d outils pour les gérer et la construction de l application avec celles-ci. Et tout ceci continue aujourd hui : tous les développeurs doivent apprendre à maîtriser ce que d autres ont créé pour faire avancer une société de plus en plus liée à l informatique Les raisons de ce sujet Tout au long de ma formation, j ai appris à maîtriser plusieurs langages de programmation. J ai commencé avec le langage C qui est un langage procédural bas niveau, puis j ai ensuite découvert la programmation orientée objets avec le C# puis le Java et le PHP. Tous ces langages sont très utilisés en entreprise. Il existe pour chacun d entre eux un nombre très important de frameworks qui permettent de compléter, de simplifier l utilisation de ces langages. Le problème est de savoir quand se servir d un langage plutôt qu un autre, sans connaître tous les outils qui sont disponibles avec lui. En entreprise, on retrouve ces langages utilisés sur différents projets. Entre les développeurs, les discussions autour des technologies, et notamment le conflit entre Java et C#, sont toujours très présentes et n apportent pas vraiment de réponse. Elles finissent souvent par un conflit idéologique. Ces personnes ont choisi ces technologies parce qu elles leur plaisaient, mais en plus de l intérêt qu a une technologie pour une personne, il faut également qu elle soit adaptée à l objectif de cette personne, à l utilisation qu elle peut en avoir. Pour les entreprises, les choix ne sont pas forcément faciles. Les clients peuvent être exigeants et imposer une 11

13 technologie même s ils n ont pas les connaissances pour apprécier la pertinence de ce choix. Les entreprises, lorsqu elles ont un choix à faire, doivent prendre en compte tous les aspects que ce choix implique : recrutement et formation des développeurs, temps de développement, sécurité, capacités matérielles, ergonomie, maintenance... Sur Internet, il est possible de trouver une multitude d informations concernant les capacités d un langage par rapport à un autre. Ces comparaisons sont souvent faites sur quelques points uniquement et ne concernent que peu de langages. Il n est pas possible de trouver un référentiel contenant une réelle comparaison professionnelle des langages. Une telle comparaison permettrait à différents acteurs de choisir des langages qui correspondraient à leurs besoins et fournir une idée des capacités de chaque langage à ceux qui ne les connaissent pas. Lors de ma quatrième année à l Exia.CESI j ai alors décidé de réaliser une étude de plusieurs langages afin de comparer objectivement leurs performances. Ce premier sujet m intéressait car il me permettait de compléter mes connaissances sur différents langages comme le C# et le C++. Après l étude théorique, je me suis rendu compte que les langages ne pouvaient être comparés car il y avait beaucoup trop de critères qui pouvaient influencer le choix d un langage pour un projet. Tous les langages ont des objectifs différents lors de leur conception. Ils utilisent des paradigmes différents, sont compilés ou interprétés. Les développeurs eux-même sont très importants dans le choix d un langage pour une entreprise. Certains n envisagent pas de se former sur certaines technologies parce qu elle ne leur plaît pas et aucune étude, aussi objective soit elle, ne pourrait imposer un tel changement chez eux. J ai pu voir cette volonté de rester sur sa technologie auprès de nombreux consultants lors de mon quatrième stage. J ai également pu appliquer pendant ce stage de nombreux processus permettant l amélioration des procédures de développement de l application. Ce sont ces processus inexistants dans mes précédents stages qui m ont permis de comprendre comment améliorer les projets quel que soit le langage utilisé. Si celui-ci rend la solution technique faisable, il est choisi par l entreprise. Il doit alors être possible d optimiser son intégration dans des processus de développement performants. Une fois que l entreprise ou les développeurs ont fait le choix du langage utilisé pour un projet, il faut mettre en place des outils qui permettront l optimisation et l augmentation de la performance des développements effectués. Afin 12

14 d acquérir ces compétences, j ai réalisé l installation d un certain nombre d outils permettant d améliorer la productivité de mes projets. Un projet en groupe a suffit à mon équipe pour valider l utilité de ces outils et de ces processus. Je souhaite donc partager cette expérience et surtout permettre aux plus petites entreprises de connaître ces procédés qui leur permettraient d améliorer leur développement. C est dans ce but que je réalise ce projet sur l intégration continue, afin de présenter ces procédés, d identifier pourquoi ils ne sont pas plus répandus et aider à les mettre en place Les langages Les langages informatiques sont très nombreux. Dans la première étude que je souhaitais réaliser, je voulais comparer les langages pour identifier le plus avantageux dans certaines situations. Comme je l ai expliqué plus haut, je ne pense pas que cela puisse toucher beaucoup d entreprises qui ont déjà un certain nombre de développeurs formés sur une technologie particulière. En revanche un axe d amélioration peut être la mise en place de procédures d intégration continue pour leurs projets. Ces procédures nécessitent l utilisation de plusieurs outils permettant par exemple l automatisation des traitements. Ces outils sont souvent relatifs à une technologie particulière. Je souhaite proposer à la fin de cette étude, une solution complète permettant l utilisation de processus d intégration continue. J ai donc décidé de ne réaliser cette solution que pour un unique langage afin qu elle soit opérationnelle et utilisable. Elle pourra servir de base pour une solution avec d autres langages. Afin d identifier le langage que j allai utiliser, j ai réalisé plusieurs recherches qui m ont guidé vers un organisme tiers qui réalise des études mensuelles sur l utilisation des langages dans le monde [43]. Cet organisme compte le nombre d ingénieurs qualifiés dans le monde entier, les cours et les vendeurs tiers qui utilisent un langage particulier, et établit son classement à partir d évaluations réalisées par des moteurs de recherche comme Google, Yahoo et Bing ainsi que d autres sites comme Wikipedia, Amazon et YouTube. Il existe beaucoup d autres études se reposant sur des bases de données différentes. Le site de LangPop.com [31] fournit des indices plus précis et plus manipulables. Via ce site, il est possible de définir quelles sources de données nous souhaitons 13

15 Figure 2 Index de popularité des langages de programmation. TiobeSoftware [43] mettre en avant (entre GitHub, Google Files, Ohloh, Craiglist, GoogleSearch). Github est un site de dépôt de source dont la popularité est en très forte hausse depuis quelques temps. Il propose des outils de recherche dans ses archives permettant d identifier les langages les plus utilisés sur cette plateforme[22]. Cependant, il est nécessaire de rappeler que nous ne connaissons pas la validité des archives 14

16 du site et qu il propose des dépôts privés uniquement pour les comptes utilisateurs payants. Certains utilisateurs n utiliseront donc jamais cette plateforme pour des sources qu ils jugent privées. Afin de compléter ces recherches, je me suis tourné vers le site d emploi informatique LesJeudis.com. Ce site est un référentiel français pour les offres d emplois dans le domaine de l informatique. Grâce au système de recherche par technologie[20], il est possible d identifier les langages les plus recherchés par les entreprises. A la date du 15 février 2014, les langages avec le plus d offres sont le C/C++(475), le Java(346), le PHP (179) et le C#(159). Il me semblait important également d intégrer ma propre expérience de ces langages dans la décision finale pour que je puisse améliorer mes connaissances de l écosystème qui m intéresse le plus. En confrontant toutes ces données, on se rend compte de l importance de certains langages dans le monde informatique. Le C reste très présent sur le marché depuis sa création. Le Java, le C# et le C++ sont les principaux langages orientés objets qui dominent le marché. Beaucoup d autres langages seraient très intéressants à intégrer dans cette étude. En effet, si aujourd hui les langages précédemment cités sont les plus utilisés au monde, certaines technologies évoluent très rapidement. Le PHP, le Python et le JavaScript sont des langages très utilisés dans certains domaines de l informatique. Afin de limiter la complexité de ce document, je ne vais présenter que les langages C, C++, C# et Java de manière théorique avant d affirmer la décision du langage choisi Le C Le langage C est un langage de programmation impérative, compilé, c est à dire que le code source est traduit en langage machine avant d être exécuté, apparu dans les années 1970 en tant que langage d implémentation du système Unix. Dennis Ritchie, développeur chez Bell Labs a créé le langage C et en 1978, il publie The C Programming Language avec Kernighan, ce qui entraina une évolution importante dans le monde du développement informatique. Le système Unix s est alors développé rapidement dans de nombreux groupes industriels. L exploitation de ce système a amené le langage C à être diffusé et modifié par de nombreux participants. En 1982, le C était devenu bien différent du langage d origine de Kernighan et Ritchie. Il était nécessaire de réaliser une nouvelle standardisation. 15

17 Un comité fut réuni et pris en compte l intégralité des implémentations existantes du C pour en réaliser une standardisation unique qui a conduit au C moderne[39]. Cette norme, ANSI C, fut terminée en Une partie importante du langage C vient du langage BCPL développé par Martin Richards. Cette influence passe égalempent par le langage B écrit par Ken Thompson en 1970 chez Bell Labs pour le développement du premier système Unix. Ritchie en collaboration avec Thompson fit évoluer le langage B de manière importante ce qui permit de créer un nouveau langage appelé le langage C. Le C est toujours très utilisé aujourd hui notamment à cause d un certain nombre de caractéristiques qui le rendent très pratique à utiliser. En effet, le langage possède un compilateur qui lui permet d être portable sur toutes les machines. Il introduit le concept de librairie standard disponible en dehors de l implémentation du langage sur les différentes machines. C est un langage de niveau moyen, sa syntaxe est assez simple par rapport aux langages comme l Assembleur, mais il permet d accéder aux capacités du matériel si besoin. Il permet d accéder aux fonctions bas niveau de la machine mais également un ensemble de fonctions permettant de réaliser des traitements de manière simple sans accéder au matériel directement. Le code rédigé en C est très rapide, presque aussi rapide que le code Assembleur. Il est donc utilisé dans beaucoup de types de projet, notamment systèmes, de compilateurs, d assembleurs, d éditeurs de texte, de drivers, de bases de données, d interpréteurs de langage, d utilitaires... Il est souvent abordé comme premier langage par beaucoup de développeurs car il permet de comprendre comment la machine gère son espace mémoire[10] Le C++ Le langage C++ est une amélioration du C réalisée par Bjarne Stroustrup alors qu il travaillait sur sa thèse. Il commença par travailler avec le langage Simula[41] qui est considéré comme le premier langage orienté objets. Plus tard, il travailla sur le C avec des classes, c est à dire qu il utilisa le C en essayant de l améliorer pour l aider à intégrer les caractéristiques du paradigme objet sans sacrifier sa portabilité et sa rapidité de traitement. Ce langage intègre les classes, le principe d héritage simple, la vérification d un typage fort et les arguments par défaut pour les fonctions en plus de toutes les fonctionnalités du C. 16

18 En 1983, le nom du langage fut changé de C with Classes à C++. À ce moment de nombreuses fonctionnalités ont été ajoutées au langage avec la virtualisation, la surcharge, le mot clé const. En 1985, Stroustup publie le livre The C++ Programming Language. Ce livre va servir de référence pendant quelques années avant la standardisation officielle de Tout au long de son existance, le C++ sera en permanence amélioré ce qui compliquera la tâche de création de la référence par les comités de standardisation dont les derniers travaux sur le C++ ont été publiés en 2011[8]. Le C++ est donc un langage de programmation normalisé par l ISO (Internationel Organization for Standardization [9]). C est un langage compilé possédant un typage fort demandant au développeur de maîtriser ce qu il réalise. Il supporte également un typage static ou dynamique c est à dire que le type d une variable est vérifié soit lors de la compilation, soit lors de l exécution. Le C++ permet l utilisation de plusieurs paradigmes notamment procédural et orienté objets. Comme le C++ se base sur le langage C, il bénéficie de sa portabilité, et il est compatible avec toutes les librairies du langage C avec peu ou pas de modifications. Avec l importance du C dans le monde et les nouvelles fonctionnalités qu il apporte, le C++ a vite été très populaire, la communauté est très importante autour de ce langage lui permettant d avoir une importante quantité de librairies open sources[5]. Le C++ est utilisé pour sa rapidité et ses performances très élevées dans des domaines où le temps de réaction est très important. C est le cas de certaines applications militaires, des outils financiers et de l industrie du jeu vidéo qui utilisent très largement ce langage Le Java Le Java est né de la volonté d ingénieurs de l entreprise Sun de créer un langage qui pourrait fonctionner sur de petits appareils électroniques en Pour cela, ils se sont basés sur le concept du Pascal UCSD de machine virtuelle. Ce concept reprend l idée de traduire premièrement le programme source en langage intermédiaire commun à toutes les machines. Ce code intermédiaire, que l on nomme Byte Code, est ainsi portable sur n importe quelle machine. La seule condition est que la machine de destination possède un programme appelé machine virtuelle permettant l interprétation du Byte Code. Ce projet n a pas abouti immédiatement. 17

19 Il fut repris lors de la sortie du navigateur Web HotJava, capable d exécuter des applets écrites en Byte Code[24]. Dès lors, le langage s est fortement développé grâce à son utilisation par les autres navigateurs et le développement de plusieurs versions qui ont permis l amélioration du langage avec l ajout de nombreuses bibliothèques de fonctions. Le Java est un langage dit pur langage de Programmation Orienté Objet (POO). Par nature un programme possédera obligatoirement une classe et il instanciera plusieurs objets. Il existe quelques exceptions à cette pureté du langage. Les types primitifs sont utilisés pour représenter les entiers, les nombres flottants, les caratères et les booléens. Ces variables ne sont pas des objets mais seront présentes en tant qu attributs des classes. Certaines méthodes de classe (déclarées avec le mot clé static) pourront être utilisées indépendamment d une instance de classe. On peut donc retrouver les procédures ou des fonctions des langages non objets mais ce n est pas le coeur du langage Java. La portabilité du langage Java est une de ses principales caractéristiques. En effet, on dit d un langage qu il est portable si un code source peut être utilisé sur différents environnement en ne nécessitant qu une nouvelle compilation. Le Java, lui, va plus loin grâce à la Machine Virtuelle ou Système d éxécution Java et au Byte Code. Après la compilation d un code Java, ce Byte Code peut être lu indépendamment de la plateforme sans nécessité de modification. L environnement définit les caractéristiques complètes des types primitifs ce qui permet d être assuré d avoir le même résultat quel que soit l environnement d exécution. Le Java s est grandement inspiré du langage C++. La définition du langage s est faite à partir d une base existante de C++, Fortran, Lisp et SmalTalk. Le Java est beaucoup plus simple que le C++. Pour cela, ses concepteurs ont dû retirer plusieurs caractéristiques du C++, les pointeurs, la surcharge d opérateurs et l héritage multiple.[33] Le Java a été développé à l origine par James Gosling chez Sun Microsystems qui a été acheté par Oracle Corporation en En 2007, Sun a modifié la license de tous ses produits Java en choisissant la licence GNU General Public License rendant le langage, la machine virtuelle et les librairies Java open sources. 18

20 2.1.7 Le C# Le langage C# a été créé par Anders Hejlsberg pour Microsoft en 2000 et a été introduit en même temps que la plateforme.net, produit phare de Microsoft. C est un langage à typage fort respectant plusieurs paradigmes de programmation tels que le procédural, l orienté objets et l orienté composants. L objectif de la création de ce langage était de fournir aux développeurs un outil aussi performant que le C++ avec la facilité de création d interfaces graphiques du Visual Basic.[28] Ce langage est tourné vers l efficacité maximale. Les auteurs du langage ont souhaité faire un outil simple d utilisation supprimant les tâches répétitives et laborieuses pour les développeurs (création d interfaces, contrôles standards, gestion d événements...). Il intègre notamment une détection d utilisation d objets non initialisés, une gestion des espaces mémoire... Le C# est orienté composants, c est à dire qu il intègre un certain nombre de mots clés pour créer les interfaces des composants. Le C# fait partie de la plateforme.net, outil créé par Microsoft dans le cadre de sa nouvelle stratégie. Cette plateforme s oriente sur un ensemble de services installés localement ou accessibles par le Web. Les composants de cette plateforme respectent tous la Common Language Specification qui est l ensemble des règles du.net. Ainsi, le C# met en avant la capacité d interopérabilité de la plateforme. Tout composant écrit dans un langage est utilisable dans un autre. Le C# est un langage objet pur. Toutes les variables du langage sont des objets même les types de variables standards tels que int ou float. Les programmes générés par le Framework.NET peuvent être exécutés sur toutes les plateformes possédant un Framework.NET. Sur un concept semblable à la machine virtuelle de Java, le C# posséde un Common Language Runtime qui fournit un environnement d exécution avec des services comme le Garbage Collector pour la gestion de la mémoire[46]. L environnement fourni par Microsoft permet d exécuter des programmes.net uniquement sur les systèmes Windows. En 2004, un projet open source, Mono[13], a été initialisé afin de créer un framework semblable à la plateforme.net disponible sur MacOS X et Linux. L entreprise Novell, qui maintient ce projet, fut poursuivie en justice par Microsoft jusqu à un accord en 2006[12]. 19

21 2.1.8 Choix du langage Afin de toucher le plus de personnes possibles et de compléter mes connaissances sur l écosystème associé, je vais utiliser le langage Java. De nombreux outils sont disponibles pour cet environnement et il est très largement utilisé dans les entreprises. De plus, c est un langage que j apprécie personnellement et dans lequel j aimerais me spécialiser. Il fonctionne assez facilement sur les plateformes majeures que sont Microsoft Windows, Mac OSX et GNU/Linux. Son fonctionnement sur le paradigme objet permet la réalisation de projets d envergure avec notamment des normes comme les design patterns du Gang of four (GoF). C est un langage qui bénéficie d une grande expérience et d une communauté active ce qui se traduit notamment par la présence de nombreux Framework open sources. 20

22 2.2 L intégration Continue L Intégration Continue (IC) est une pratique issue de l Extreme Programming. Elle fait partie d un ensemble de processus permettant aux développeurs travaillant en Extreme Programming d assurer un fonctionnement permanent de l application. L IC est une pratique de génie logiciel visant à accélérer la livraison des applications en réduisant le temps d intégration. Elle va mettre en oeuvre un ensemble de moyens pour que les processus d intégration d un projet (compilation, exécution des tests, reconstruction de la base de données, déploiement, inspections) deviennent une étape presque invisible. Toutes ces étapes doivent être rapides et reproductibles simplement pour que les développeurs ne soient pas constamment obligés de s en charger. Ce travail doit être simplifié pour tous les acteurs présents autour du code (développeurs, testeurs, intégrateurs) Définition et objectifs L intégration est une activité majeure qui consiste à regrouper les différents codes sources de l application et appliquer différentes vérifications de fonctionnement ou de qualité. Elle est souvent complexes car elle comprend un grand nombre d acteurs et de nombreuses interactions avec des outils différents. Au fur et à mesure de la croissance d une application, l effort demandé pour l intégration est de plus en plus important. Chaque fonctionnalité doit être de nouveau vérifiée à chaque intégration afin d éviter les phénomènes de régression (fonctionnalité implémentée et rendue inopérante par un changement récent). L objectif de l IC d une application est de réaliser une application binaire à partir de code source à travers un processus fiable, prédictif et largement automatisé. Ceci permet de réduire le temps et les risques dus à la livraison aux utilisateurs finaux, car l application est à tout moment fonctionnelle. La collaboration entre les développeurs, les testeurs et les personnes chargées de la livraison est également améliorée grâce à des retours d expérience plus réguliers. Dans un contexte sans ce type de processus, on retrouve souvent des situations récurrentes. Les équipes en charge du développement se contentent de tester sur un environnement local. Les phases de tests sont longues et réalisées manuellement et des régressions apparaissent sans être traitées tout de suite. 21

23 2.2.2 Composant de l IC Plusieurs composants principaux sont nécessaires pour mettre en place des processus de l IC. Un gestionnaire de version dans lequel les développeurs vont déposer leur code et assurer un suivi de l évolution du code source d un projet. Il centralise l ensemble du code source des développeurs. C est avec ce dépôt que les outils vont réaliser la construction des binaires dont ils sont responsables. Il est également nécessaire d y associer un mécanisme permettant la détection des changements dans le code afin de déclencher les processus automatisés. Des scripts implémentent les processus de l IC et exécutent toutes les étapes dans un ordre prédéfini. Ils fournissent l automatisation des processus de l IC que sont la compilation, l exécution des tests, l inspection du code et le déploiement. L environnement que l on va utiliser pour la mise en place de ces scripts va influencer le choix de la technologie de ces scripts. Ils peuvent donc se présenter sous la forme d outils complexes comme un serveur d intégration continue ou plus simple avec des outils de build comme Maven et Ant ou des scripts Shell ou Python. Enfin, afin d avertir les équipes de développement et les personnes responsables de l intégration et du déploiement, des notifications doivent être émises en cas de réussite ou d échec de l étape. Ces notifications peuvent prendre des formes diverses : , flux RSS, message instantané. L IC est intégrée à un ensemble de processus d intégration. Ce type de processus est composé de plusieurs éléments comme la génération de code source assurée par les développeurs, la compilation, l exécution de tests, la génération de documentation... Ces éléments ne sont pas tous obligatoirement présents dans le processus d intégration mais leur automatisation complète la valeur qu apporte l intégration. Il va faire intervenir de nombreux acteurs et est généralement représenté comme un ensemble d étapes linéaires jusqu à la livraison effective. Un serveur d IC a plusieurs rôles. Il doit surveiller les changements effectués sur le gestionnaire de versions ou sur le système de fichiers, préparer l environnement d exéctution de l application, orchestrer la construction et proposer un retour notamment via les mécanismes de notifications ou des tableaux de bords présentant les résultats. 22

24 2.2.3 Fonctionnement simple Les processus d IC sont mis en place en début de projet afin de suivre l évolution de celui-ci. Tout commence sur le poste de développement. Chaque développeur, lorsqu il rédige du code, doit associer des tests à son code afin d en vérifier le fonctionnement. Une fois la fonctionnalité terminée, il doit exécuter tout ou partie des tests présents sur le projet afin de vérifier qu il n a pas commis d erreur entraînant une régression sur le reste de l application. Si tous les tests sont positifs alors il peut partager son code. Pour cela, il va utiliser un outil de gestion de versions ou versionning. Son partage va être marqué par un identifiant unique et il va commenter son ajout de code en expliquant ce que contiennent ces modifications. Le code est ainsi envoyé sur le dépôt central du gestionnaire de versions qui va l intégrer au reste du code existant. Le développeur peut également récupérer le code présent sur le dépôt central qu il ne possède pas en local grâce à ce même gestionnaire qui va comparer les deux versions du code source. Cet outil permet donc les échanges entre développeurs de manière simplifiée, historisée et sécurisée. En cas de conflit sur un même fichier, le développeur doit résoudre le problème, ce qui assure une bonne intégration de toutes les sources. Une fois le code partagé et regroupé, un outil de build va être appelé afin de vérifier la bonne compilation du code source. Cet outil comme nous l avons vu peut prendre plusieurs formes. Il va être appelé de manière périodique ou après une modification effectuée sur le gestionnaire de versions. Il récupère le code source à partir du dépôt et en réalise une construction ou build. Ceci va permettre de vérifier qu il n y a pas d erreur fatale de syntaxe dans le code partagé. À la suite de cette construction, l ensemble des tests du projet va être exécuté afin de vérifier que l intégration des différentes parties du code source n a pas provoqué de régression. Cette analyse est souvent accompagnée d un programme qui va étudier les lignes testées et celles qui ne le sont pas. Ceci permet d avoir des rapports utiles aux développeurs qui peuvent compléter les tests afin d assurer un niveau de test optimal. C est également à la fin de la construction que l on va généralement réaliser une étude de la qualité logicielle. Je décrirai la qualité logicielle dans l étude car c est un vaste sujet. De manière concise, la qualité logicielle est un indicateur permettant d évaluer la maintenabilité, la performance, la facilité de transfert entre 23

25 deux équipes et la sécurité d un code source. Ces rapports de qualité donnent aux développeurs des indicateurs pour leur permettre d améliorer leur code au delà de la partie fonctionnelle. Une fois la construction terminée, le résultat est mis à disposition dans un dépôt. Il peut également être déployé sur une instance très proche de l environnement de production afin d en vérifier le bon déploiement. Des procédures qui dépassent l intégration continue pour aller vers le déploiement continu sont possibles à cet instant mais ne sont pas prises en compte pour ce projet. 24

26 Figure 3 Schéma des flux au sein de processus d intégration continue 25

27 2.2.4 Réduction des risques Plusieurs risques sont réduits grâce à la mise en place de procédures d IC. Le premier est l augmentation des coûts due au fait que certaines erreurs ne sont corrigées que lors de la mise en production. Environ 5% des problèmes produits après la livraison représentent 95%[49] des coûts de correction. En effet les corrections doivent être réalisées de manière très rapides pour ne pas impacter le client et impliquent souvent des redéploiements assez complexes. Pour ce cas, l intégration continue détecte les erreurs très rapidement et permet aux développeurs de les corriger. Le second risque est le manque de cohésion au sein des équipes de développement. Le travail en équipe sur des développements logiciels n est pas anodin, les différents membres de l équipe doivent échanger pour s accorder sur le travail réalisé. Très souvent les développeurs se retrouvent avec des composants qui ne sont pas compatibles car la communication a été trop pauvre pendant la phase de développement. Ils doivent alors faire manuellement des tests d intégration pour vérifier le bon fonctionnement de l ensemble des composants. L IC va permettre d éviter ces tests manuels en rendant cette phase d intégration invisible pour le développeur. Les changements incluant des régressions sont tout de suite détectés et remontés aux développeurs pour être corrigés. La qualité du code source est le troisième risque que va gérer l IC. En effet, lors des développements, les acteurs responsables du code doivent respecter des bonnes pratiques. La complexité, la réplication du code, la documentation et les normes de codage sont des éléments que l IC va estimer afin de réaliser des comptesrendus aux responsables qui vont mettre en place des mesures d amélioration. Ces comptes-rendus vont permettre de linéariser le code avec ces bonnes pratiques et donc d améliorer la qualité générale du code source. Lorsqu un projet grandit, il devient de plus en plus difficile de s assurer de son parfait fonctionnement. Des changements ont lieu dans certains endroits restreints du code qui finalement vont impacter des parties de code éloignées. Ces modifications peuvent alors provoquer des régressions qui sont difficilement détectables. Ce manque de visibilité est atténué avec l IC. Les nombreux tests mis en place et exécutés à chaque intégration de code va assurer le fonctionnement de l application après chaque modification. Ils vont également permettre une estimation de la 26

28 couverture du code et donner de la visibilité sur le contenu actuel de l application. L objectif principal d un projet d application est de fournir un livrable à un client afin qu il soit déployé sur un environnement de production. Ce dernier n est pas le même que celui de développement, il doit donc être testé avant cette livraison. L IC permet de s assurer, à travers des tests réalisés sur un environnement similaire à la production, qu une application fonctionne à tout moment dans le projet. Le déploiement est automatisé afin de limiter les interventions nécessaires de la part des développeurs ou des responsables opérationnels. 2.3 Les tests Les tests ont une très grande importance dans le développement logiciel. Ils assurent aux développeurs que le code est fonctionnel et donc réduit les inquiétudes d avoir impacté le travail des collaborateurs. Ils sont une source d indicateurs importante afin de vérifier les performances, la croissance et la qualité du code produit. Un projet de développement a pour objectif de confier une application fonctionnelle au client afin qu il la déploie sur son environnement. Les tests sont la première étape qui permet de vérifier le fonctionnement de l application (la seconde étant le déploiement sur l environnement cible). Dans les processus de l IC, les tests ont un rôle capital car ce sont eux qui vérifient la bonne intégration des composants et le fonctionnement de l application après le processus d intégration. Ils doivent avant tout être automatisés afin qu aucune manipulation ne soit nécessaire de la part des acteurs du projet. De nombreux outils permettent l exécution de ce type de tests et notamment la suite xunit. Cette suite est un ensemble de librairies de tests disponible pour une large variété de langages. Dans les processus d IC, les résultats des tests sont conservés afin de détecter de possibles problèmes de performance ou à des fins statistiques. Il est très important pour les responsables de l IC de ne pas ignorer ces tests. Tous les tests présents dans une application sont des sécurités qui permettent de vérifier son fonctionnement. En cas d erreur sur un test, une correction doit être effectuée très rapidement. Aucun test ne doit être ignoré lors de l intégration. Avant chaque partage de code, les développeurs doivent avoir la possibilité d exécuter tous les tests existants afin de vérifier qu aucune régression n ait été créée dans le code. Pendant longtemps, les tests unitaires ont été considérés comme étant sec- 27

29 ondaires par rapport au code principal d une application. Aujourd hui, ils ont une importance majeure. Une méthode les met d ailleurs au premier plan : TDD (Test Driven Développement). Dans cette méthode, les tests sont rédigés avant les fonctionnalités. Les tests correspondent aux spécifications de la fonction testée, celle-ci doit répondre exactement ce qui est attendu par le test Catégorie de tests Au sein de l IC, l objectif est d avoir des tests pertinents et rapides afin de ne pas ralentir le reste du processus. Les tests vont ainsi être séparés en différentes catégories. Un test unitaire ne possède aucune dépendance avec d autres composants en dehors de celui testé. Il doit uniquement concerner une petite part de code ne faisant que quelques lignes sans se préoccuper de base de données, de système de fichier ou de classes autres. Ce type de test doit être utilisé le plus souvent possible afin de tester toutes les actions minimalistes de l application. Ils doivent être simples et très rapides. Un test de composants va au contraire du test unitaire avoir pour objectif de tester un ensemble de code ayant une dépendance avec un composant externe (base de données ou système de fichiers). Ces tests sont plus longs à exécuter car ils nécessitent le concours d éléments extérieurs au code source de l application. Ils vont souvent avoir besoin de Mocks, des faux services qui vont fournir à l élément testé les données nécessaires à la validation du test. Les tests de déploiements vont vérifier que le déploiement et la configuration de l application sont pertinents et fonctionnels. Ces tests sont importants dans le cadre d un fonctionnement en livraison continue. Un test fonctionnel vérifie le comportement de l application du point de vue de l utilisateur. Ces tests également appelés tests d acceptation, vont tester une fonctionnalité entière de l application en se basant sur un scénario décrit par le responsable métier du client. Ces tests sont extrêmement répétitifs si effectués manuellement car ils se constituent principalement de saisies de formulaires, de clics sur des interfaces graphiques. Des outils existent pour s interfacer avec les frameworks de tests et outils d IC : Selenium pour les interfaces Web et Abbot pour des clients lourds. 28

30 Enfin les tests de capacités n ont pas pour objectif de tester les fonctionnalités mais les performances des applications dans l environnement de production. Ils vont déterminer la charge qu est capable de supporter tout l environnement de prodution avec l application et quelles sont les performances associées. 29

31 3 Etude Les processus d intégration continue (IC) assurent une qualité du code ainsi qu une application fonctionnelle à tout moment du développement. C est un ensemble de pratiques qui limite les coûts de développement supplémentaires, les erreurs de communication, les erreurs lors du déploiement sur l environnement de production et la perte de visibilité sur le projet. L IC n est pas relative à un langage et s applique à toutes les pratiques de développement. L objectif principal de cette étude est de déterminer pourquoi l IC n est pas présente au sein de toutes les entreprises éditrices de logiciels. Pour cela nous allons réaliser une étude auprès de plusieurs entreprises à l aide d un questionnaire. À partir de ces réponses nous pourrons chercher une solution permettant de répondre aux besoins de ces entreprises. La dernière étape sera la présentation de cette solution. 3.1 Questionnaire J ai réalisé ce questionnaire sur une instance personnelle de LimeSurvey, un outil open sources. Ce questionnaire doit principalement m aider à déterminer quels sont les types d entreprises qui n utilisent pas l IC et quelles en sont les raisons. J utilise également ce questionnaire dans le but de découvrir les outils utilisés par les entreprises qui appliquent l IC. Afin de toucher le plus d entreprises possibles, j ai publié mon questionnaire sur le réseau professionnel LinkedIn et l ai envoyé aux étudiants de l Exia ayant déjà fait un stage. Le questionnaire a été complété 19 fois par 17 entreprises différentes. Ce nombre n est pas représentatif de l ensemble des entreprises françaises mais me permet de voir certains écarts entre les entreprises. En effet, sur cet échantillon, les profils d entreprises sont vraiment différents. Leur date de création tout d abord s étend entre 1967 et 2014 avec plus de la moitié de ces entreprises créées dans les années Elles emploient entre 4 et personnes. Le chiffre d affaires des entreprises qui ont répondu au questionnaire est compris entre 400 mille et 10 milliards d euros. L ensemble de ces données a une valeur indicative. Elles me permettent de définir le profil des entreprises qui seraient intéressées par la solution. Le dernier indicateur que j ai choisi d utiliser est le cœur de métier des sociétés. En effet la solution d IC ne concerne que les éditeurs de logiciels, ou des 30

32 entreprises réalisant de la Tierce Maintenance Applicative ou du conseil. Presque toutes les personnes ayant répondu au questionnaire sont concernées, on retrouve principalement des sociétés éditrices de logiciels à 80% des réponses. La deuxième partie du questionnaire me permet de connaître les technologies et outils utilisés par les entreprises dans le cadre de leurs projets de développement. Ceci oriente et valide mes choix en ce qui concerne le choix de la solution. Les outils doivent en effet correspondre aux besoins mais aussi être performants et fonctionnels. Le fait que d autres entreprises les utilisent augmente la pertinence de l outil en termes de capacités. Certaines entreprises utilisent plusieurs outils, les pourcentages représentent donc une utilisation non exlusive. Ainsi, les langages les plus utilisés sur les 17 entreprises intérrogées sont le JavaScript (63%), le Java (53%), le PHP (53%) et le C# (42%). En termes d outils de gestion de versions, ce sont Git (53%), Subversion (37%) et TFS(21%) qui sont les plus représentés. Les logiciels suivants sont directement liés à des processus d intégration continue et donc n ont pas été affichés pour les entreprises n utilisant pas ces processus. Les outils de gestion de build sont assez nombreux mais on retrouve Maven (32%) et Ant (16%) dans les plus utilisés. Derrière ce sont Grunt pour le JavaScript et MSBuild pour le C# qui sont les plus utilisés (11%). L outil de build le plus mis en place est Jenkins avec 26% des entreprises ayant fait le questionnaire. Très peu d outils de qualité sont utilisés mais SonarQube apparaît dans trois réponses. Ces indicateurs confirment mon choix du langage sur lequel je vais travailler. Ils me donnent également de nombreuses pistes des recherches concernant les outils à inclure dans la solution finale. Enfin, le dernier ensemble de questions est dirigé vers les raisons de la non utilisation de processus d IC. Sur les 17 entreprises ayant répondu au questionnaire, neuf n utilisent pas de processus d IC. Cette part est très importante lorsque l on sait que près de 80% des particpants sont éditeurs de logiciels. La principale raison justifiant cette absence est le fait que l intégration continue est inconnue par l entreprise (32%). Les raisons suivantes sont le temps de mise en place (16%), le coût (11%) et la complexité de mise en place (5%). On remarque que ce sont les petites et récentes entreprises qui n utilisent pas ces processus. Il est possible de faire un lien entre le manque d expérience et de moyen de ces sociétés avec le fait qu elles ne puissent pas ou ne veulent pas investir du temps et de l argent dans l intégration continue. 31

33 Ce questionnaire nous a permis de découvrir quelles sont les raisons qui empêchent les entreprises d utiliser les processus d IC. Il ne faut pas considérer ce questionnaire comme étant une réponse universelle car trop peu de réponses ont été données. Cependant, nous avons pu avoir des retours de la part d entreprises aux profils très différents. Il est évident qu il y a un manque autour de l intégration continue qui empêche ces processus de se développer et notamment au sein des petites structures. 3.2 Outils Le questionnaire nous a donné des pistes concernant les outils à utiliser pour la solution finale. Une description des outils utilisés pour la solution est nécessaire afin d en dégager les avantages par rapport à leurs concurrents sur le marché Automatisation avec Maven L Apache Software Foundation est un acteur très important du monde Java. Elle a développé de nombreux outils et librairies pour le développement d applications Java et d autres langages. Apache Maven est l un d entre eux. Cet outil est réservé à la gestion et à l automatisation de la production des projets en Java. Il permet la production d un logiciel à partir de ses sources en optimisant les tâches intermédiaires et en garantissant le bon ordre de fabrication. Il permet de supprimer les tâches difficiles du processus de build. Les versions 1 et 2 de Maven ont été créées en parallèle. Les versions suivantes du logiciel utiliseront le modèle de Maven 2. Ce logiciel est publié sous licence libre Apache 2.0. Je ne parlerai ici que de Maven 2 et 3 qui apparaîtront sans distinction sous le nom générique de Maven. Maven se base sur une approche déclarative grâce à un fichier XML situé à la base du projet, le Project Object Model ou POM. Chaque projet est configuré dans ce fichier à travers plusieurs balises. L architecture de ce document XML permet aux projets Maven d être divisés en sous-modules. Ces sous modules possèdent chacun un pom.xml et héritent de la configuration établie dans le pom parent situé à la racine du projet. Ce fonctionnement permet le bon découpage de la configuration mais aussi sa factorisation. Maven permet la déclaration de dépendances qui seront résolues lors de la compilation du projet. Ainsi, lorsqu une librairie est nécessaire pour le fonction- 32

34 nement du projet, elle doit être déclarée en dépendance dans le pom.xml. Maven va la télécharger et la stocker dans un dépôt local. Il pourra ainsi l insérer dans le package final de l application dans le dossier lib. Un dépôt central de Maven est disponible en ligne et paramétré automatiquement à chaque installation. Ce dépôt contient de nombreuses librairies avec leurs versions. Ce dépôt est ouvert ce qui peut entraêner des erreurs ou des incohérences sur certains projets qui ne sont pas beaucoup utilisés. Ce fonctionnement simplifie grandement le développement sur plusieurs postes de développement. En effet, les développeurs n ont pas besoin de télécharger eux-mêmes les librairies qui sont trop imposantes pour passer par l outil de gestion de versions. Des profils sont également paramétrables via ce document XML. Ils apportent une configuration dynamique en fonction du profil choisi lors de la construction (par exemple : la définition de propriétés contenant les accès à la base de données pour avoir une base par environnement de travail). Les créateurs de Maven ont vraiment souhaité simplifier son fonctionnement en utilisant des conventions plutôt que des configurations complexes. Ainsi, l architecture des projets Maven respecte la convention suivante : / : racine du projet contenant le pom.xml /src : les sources du projet. /src/main : les fichiers de l application principale du projet /src/main/java : les sources java /src/main/resources : les ressources du projet (configuration, propriétés,...) /src/main/webapp : les fichiers liés aux applications Web (HTML, JavaScript, CSS, et configuration web.xml) /src/test : les fichiers de tests de l application /src/test/java : les fichiers Java de tests de l application /src/test/resources : les ressources des tests (jeux de données, configuration,...) /target : tous les fichiers résultats, les résultats des tests, les packages générés (War, Jar) Cette convention peut être modifiée par l ajout de configurations. Maven possède un cycle de vie assez strict mais dont chaque étape passe obligatoirement après la validation de la précédente. compile test 33

35 package install deploy Ainsi, l exécution d une étape va tout d abord vérifier si l étape précédente a bien été exécutée et si c est le cas elle sera lancée. Ces étapes du cycle de vie de Maven sont appelées des goals. D autres goals sont disponibles mais ils ne font pas partie du cycle de vie normal de construction de Maven (clean, assembly, site...). Ils permettent principalement d ajouter des actions à réaliser en plus de la construction du projet, comme par exemple la suppression des anciennes constructions. Apache Maven est l outil le plus utilisé aujourd hui dans la gestion de construction de projets Java. Son principal concurrent est Apache Ant mais celui-ci est beaucoup plus complexe à configurer. Contrairement à Maven qui se base sur des conventions pour simplifier la configuration, Ant va nécessiter une configuration poussée pour réaliser un projet simple. Un autre concurrent notable apparu récemment est Gradle. Cet outil bénéficie du fonctionnement de Maven en favorisant la convention à la configuration et la flexibilité de Ant. Il permet la description des tâches de construction dans le fichier de configuration dans le langage Groovy. Dans la solution proposée nous allons utiliser Maven qui est l outil le plus utilisé dans le monde Java.[44][?] Versionning avec Git La gestion de version ou Versionning est un système très important dans le cadre de développement de projets logiciels. Chaque développeur va partager de manière régulière son code sur un dépôt commun pour le projet. Chaque partage, appelé commit, va contenir les nouvelles versions des fichiers de code. Ces versions sont conservées tout au long de la vie du projet pour permettre un suivi de l évolution du code. En cas d erreur provoquée à une certaine version, il est donc possible de revenir à une version antérieure à l erreur. Pour réaliser cette gestion de versions, il existe de nombreux logiciels : Git, Subversion, Mercurial, CVS... Tous ces logiciels ont un fonctionnement commun qui est le partage des codes sources sur un dépôt. Mais deux branches majeures se détachent par la suite. Les systèmes de gestion de versions centralisés sont orientés autour d un unique dépôt de versions de référence. Seul le dépôt central délivre des numéros de versions pour 34

36 les partages effectués. Ce type de gestion est plus léger car il limite le nombre de versions mais est plus contraignant car il empêche le travail hors connexion ou le travail sur des branches expérimentales. Subversion est un système de gestion de versions centralisé. Le second type de gestion est la gestion décentralisée qui permet le travail individuel et désynchronisé et par la suite le partage entre collaborateurs. Il existe plusieurs dépôts pour un même logiciel, le principal et celui de chacun des développeurs. Chacun de ces dépôts peut générer des numéros de versions qui seront récupérés par les autres en cas de partage du code. Ce type de gestion possède de nombreux avantages : pas de point sensible unique, le dépôt central n est pas le seul à posséder toutes les versions permet le travail hors connexion le merge-request qui est une demande faite au dépôt central pour ajouter son code à la branche principale. L administrateur donne les droits sur le dépôt après avoir vu le travail réalisé le travail brouillon ou expérimental est réalisé en local le dépôt central ne possède que des versions de partage en théorie fonctionnelles Son principal inconvénient est le fait que le nombre de versions soit beaucoup plus important. Si chaque utilisateur réalise plusieurs versionning de son coté, lors de la mise en commun, l historique des versions grandit d autant. La récupération du dépôt est donc plus longue et lourde à cause du téléchargement de toutes ces versions. Git est un des systèmes de gestion décentralisée les plus importants aujourd hui. Il est notament très utilisé dans le cadre des projets open sources. Le projet a été initié par Linus Torvald, créateur de la première version du noyau Linux, et est publié sous licence libre GPL2. Il est disponible sur toutes les plateformes et possède plusieurs interfaces graphiques entièrement conçues par la communauté de développeurs du projet ou par des entreprises. GitLab est une interface Web développée par l entreprise GitLab B.V. sous licence MIT. Cette interface permet la gestion des dépôts de code Git sur une machine GNU/Linux. Il rend facilement accessible la gestion des utilisateurs et de leurs droits d accès aux dépôts ainsi que le parcours du code et la gestion de demandes de fusion. En juillet 2013, le projet a été scindé par l entreprise en deux projets distincts GitLab Community Edition sous licence libre et GitLab Enterprise Edition sous licence 35

37 propriétaire. Git est le système de gestion de version qui est de plus en plus utilisé car il permet un meilleur contrôle des partages effectués sur le dépôt central. L étude réalisée par le questionnaire montre que Subversion et Git sont très proches mais les projets récents tendent à utiliser Git. C est donc cet outil que nous allons utiliser dans la solution finale. Pour l interface graphique client, nous utiliserons l interface graphique fournit avec le logiciel. Cela nous permet d être plus précis dans les fichiers qui composeront la version et évite l ajout de fichiers de tests modifiés par chaque développeur. [7][34] Serveur d intégration avec Jenkins Jenkins est un projet open sources écrit en Java. Il est originaire du projet Hudson initié par SunMicrosystems. Au rachat de Sun par Oracle, ce dernier a souhaité imposer une licence restrictive sur le projet Hudson. La communauté a alors décidé de réaliser un fork, c est à dire récupérer le code libre de Hudson pour continuer le projet sous le nom de Jenkins. Cet outil permet la réalisation de l intégration continue de projets de développement logiciels. Il s exécute sur un serveur grâce un conteneur de servlet comme Apache Tomcat. A la réception d un message, il va exécuter une procédure de construction du logiciel. Cette procédure de construction va suivre différentes étapes importantes dont la réalisation des tests (avec Junit par exemple qui est intégré nativement). Différents plugins permettent le paramétrage de ces procédures de construction. Il est possible d utiliser Maven pour réaliser la construction ce qui permet de bénéficier de tous ses avantages concernant la configuration et la gestion des dépendances. Le message initiateur de la construction peut prendre plusieurs formes : un commit sur le système de gestion de versions du projet, l activation d une tâche périodique (CRON), la fin de la construction d un autre projet ou à l appel d une URL spécifique. Ainsi, il est possible de réaliser une construction à chaque partage de code afin de vérifier que le code envoyé ne cause pas d erreur sur l application entière. Cela permet de s assurer du bon fonctionnement de l application à tout moment de son cycle de vie. Mais la réalisation d une construction et de tous les tests associés est une activité consommatrice de ressources serveurs. Il faut donc paramétrer la construction en fonction des besoins et des ressources 36

38 que l on peut allouer à Jenkins. Une fois le message reçu, Jenkins va lancer la procédure paramétrée de construction. Si une erreur est rencontrée lors de la construction, par exemple une erreur de compilation des sources du projet, la construction est marquée en échec. Les personnes désignées reçoivent un mail indiquant l échec avec un lien vers le rapport de la construction. Dans ce rapport est présent le log complet de la construction qui permet aux personnes responsables de l intégration d identifier l erreur. En cas de succès, les tests sont exécutés. En cas d échec de l un des tests, la construction est indiquée instable. En cas de succès de toute la procédure, tous les rapports sont publiés. Parmi les concurrents de Jenkins, on retrouve CruiseControl publié sous licence BSD. Cet outil permet la construction de code source Java et.net via CruiseControl.NET. Il possède une interface graphique illustrant l évolution de la construction mais la configuration doit être réalisée manuellement dans les fichiers XML du logiciel. Apache Continuum est également un concurrent de Jenkins qui est souvent revenu lors de mes recherches. Lui aussi open sources, Apache Continuum est principalement dirigé vers le Java. Tout comme CruiseControl la configuration se fait directement dans les fichiers XML. La majeure partie des fonctionnalités reste très similaire entre ces outils. On remarque que tous fonctionnent avec des plugins qui permettent de personnaliser l outil et de lui ajouter des fonctionnalités notamment avec les outils de gestion de versions, l envoi de mails, ou la construction par Maven. C est la domination du marché par Jenkins et les réponses au questionnaire qui m ont poussé à le choisir pour la solution finale.[42][11] Couverture de test avec Jacoco (Emma) Jacoco (Java Code Coverage) est un outil destiné à analyser les tests durant leur exécution afin de fournir des rapports de couverture de code. Il est installable sur l environnement de développement Eclipse et permet la récupération des rapports directement au sein de l outil. Il est distribué sous licence Eclipse Public Licence. Pour la réalisation de son étude de couverture, Jacoco va ajouter des instructions au bytecode lors de son exécution. Pour cela, il est lancé en tant que Java Agent, c est à dire qu il est exécuté dans la JVM en parallèle des tests avec un accès privilégié à la zone mémoire réservée aux tests. Cette instrumentation du 37

39 code permet la récupération de données d utilisation du code source et donc d avoir un rapport très détaillé. Les rapports de Jacoco sont générés en HTML, ils sont donc visualisables très facilement. Jenkins permet d avoir une synthèse des rapports de couverture ainsi qu un accès facilité aux fichiers de HTML de Jacoco. Dans ma recherche d un outil de couverture de code, j ai aussi rencontré Cobertura. Cobertura propose des fonctionnalités semblables à Jacoco en termes de rapport de couverture de code. Son fonctionnement est différent car pour faire une étude de la couverture, il faut exécuter une commande Maven particulière qui va modifier le code généré lors de la construction. Ce code va permettre la récupération des données de couverture. Malheureusement, cette commande Maven relance une construction complète de l application ce qui consomme beaucoup trop de ressources serveur. La configuration de Jacoco est donc plus légère que Cobertura pour des qualités de rapports équivalentes Qualité avec SonarQube La qualité logicielle est une appréciation générale du logiciel basée sur plusieurs indicateurs. La manière dont les fonctionnalités sont implémentées en respectant l architecture spécifiée lors de la définition des spécificités fonctionnelles est un indicateur orienté vers l aspect fonctionnel du logiciel. La qualité structurelle est la manière dont les besoins non-fonctionnels permettent l atteinte des objectifs fonctionnels comme par exemple la maintenabilité du code ou sa résistance. Tout l aspect fonctionnel d un logiciel ne peut être évalué que par des utilisateurs informés des spécifications attendues et par les tests réalisés tout au long de la vie de l application. Le structurel en revanche peut être évalué au niveau du code source du logiciel par des outils externes. Le Consortium for IT Software Quality[2] (consortium souhaitant créer un standard de la qualité logicielle) a défini cinq principales caractéristiques nécessaires au code source d un logiciel pour apporter une plus-value à leur créateur : Fiabilité : mesure le risque que l application s arrête de manière non contrôlée Efficacité : assure les performances de l application Sécurité Maintenabilité : contient les notions d adaptabilité, de portabilité et de transférabilité 38

40 à une autre équipe de développement Taille adaptée aux besoins De nombreuses théories ont été énoncées sur le sujet de la qualité logicielle. Je n irai pas plus loin sur ce sujet puisque ce n est pas le cœur de ce projet. Pour notre solution, j ai choisi d utiliser un outil d analyse de la qualité du code : SonarQube, publié sous licence LGPL. Cet outil réalise des analyses du code source à la demande. Il utilise un Sonar Runner qui va parcourir tous les fichiers sources afin d analyser leur contenu et identifier les défauts. Les relevés concernent principalement les indicateurs de qualité structuraux du code source. Une interface Web permet de voir les rapports présentés dans différents widgets. Si les analyses sont réalisées régulièrement, il est possible d avoir un historique de l évolution de tous les indicateurs. Cette interface permet également la visualisation des défauts directement dans le code source et l attribution des défauts à certains développeurs pour correction. De nombreux plugins sont disponibles afin de compléter les analyses de Sonar. Par exemple, le plugin Jacoco récupère les rapports faits par Jacoco lors de la construction pour afficher les résultats au sein de l interface de Sonar. Ces plugins offrent également un large éventail de langages couverts par les analyses, plus de 25 aujourd hui. SonarQube est soutenu par une communauté importante ce qui lui permet d être intégré à de nombreux outils comme Jenkins ou même l environnement de développement Eclipse. L analyse de SonarQube est composée de deux étapes : la récupération de données statiques et la comparaison à des règles prédéfinies. Dans les données statiques, on retrouve le taux de commentaires par rapport aux lignes d instruction, le taux de méthodes publiques commentées, le taux de code dupliqué ou la complexité des classes et méthodes. Ces données sont purement informatives et doivent être analysées par un responsable pour en tirer les conclusions nécessaires. Par exemple, un code dont toutes les méthodes et classes publiques sont commentées peut être de qualité même si cela représente peu de lignes de commentaires. De même, la duplication peut apparaître sur des méthodes mais ne pas être gênante, certaines d entre elles étant très proches dans leur implémentation comme par exemple la méthode equals(). La comparaison avec des règles prédéfinies fait référence aux profils de qualité. Dans SonarQue, il est possible de choisir un profil contenant un ensemble de règles de code associées à une criticité. Par exemple, la convention de 39

41 nommage de Java pour les variables est une règle de criticité Majeure dans le profil par défaut. Cette règle, si elle est activée lors de l analyse, va alors lever un défaut pour toutes les variables ne respectant pas cette convention. Les défauts seront visibles dans l interface avec un texte explicatif concernant cette règle. Les règles sont entièrement paramétrables, il est donc possible de les désactiver si elles ne sont pas pertinentes pour le projet. Il est également possible de définir ses propres règles afin de personnaliser l analyse. Cet outil d analyse de la qualité ne peut pas vérifier toute la partie fonctionnelle de l application mais en revanche elle peut permettre d uniformiser les développements et donc assurer une meilleure maintenabilité. La performance est également améliorée autour de certains tests. Par exemple, un test sur une valeur NULL va être considéré comme un défaut si une NullPointerException avait été levée plus tôt dans le code. Les concurrents de SonarQube sont assez nombreux. J ai pu en étudié quelquesuns avant de faire mon choix. JTest, Structure101, Coverity et JArchitect sont des outils de qualité propriétaires développés par Parasoft, Headway, Coverity Inc et CoderGears. Leur fonctionnement est assez proche de celui de Sonar et ils fournissent des analyses complètes sur tout type de défauts. Pour tous ces produits le prix des licences est assez élevé, de 400$ pour une licence personnelle à 4000$ pour un poste de développement. Jdepend est lui sous licence BSD, il permet une analyse complète du code mais son interface est moins facile à prendre en main que celle de SonarQube et la navigation et la recherche des défauts sont plus complexes. Le choix de SonarQube était économique et fonctionnel. Son intégration aux autres outils et ses fonctionnalités nous permettent de pousser plus loin la qualité de nos développements.[27][16] 3.3 Solution Le questionnaire nous a permis de découvrir les raisons de la faible utilisation des processus d intégraton continue. Ces raisons étaient principalement la méconnaissance, le temps, la complexité et le coût. L état de l art de ce document permet aux entreprises de découvrir l origine de l IC, son fonctionnement et ses objectifs. De nombreux ouvrages sont dédiés à ces processus. L IC est un outil qui permettra à certaines entreprises de reprendre le 40

42 contrôle de leur cycle de livraison et la maîtrise de leurs applications. Comme nous l avons vu, l IC offre la possibilité aux entreprises de développement d augmenter leur productivité en répondant à des problématiques récurrentes dans l industrie du logiciel. La mise en place de ces processus peut avoir un certain coût initial, notamment en temps puisque les équipes doivent apprendre à bien s en servir. Cependant, ce coût initial sera très vite compensé lors de la première mise en production ou la première fin de projet. Il est donc souvent avantageux pour une entreprise de considérer l IC comme un investissement à court terme. Les outils de l IC sont très nombreux. Nous avons vu que beaucoup étaient open sources et avaient des communautés importantes pour les soutenir. Ces projets sont utilisées par de nombreuses entreprises dans des processus d industrialisation. Il est donc tout à fait possible de mettre en place des processus d IC avec un coût logiciel nul. Les coûts restant sont principalement la formation et l acquisition des processus par les équipes de développement qui sont très rapidement amorties par l augmentation de la productivité. Le problème qu il reste à gérer est la complexité. Installer cinq logiciels pour en faire fonctionner un chez le client est assez compliqué à vendre et peu de petites entreprises ont véritablement l envie de prendre le temps de le faire. L acquisition du savoir-faire par les équipes de développement est assez rapide car elles y voient un intérêt lorsque le partage du collègue ne cause plus de régression sur son propre code. La solution que je souhaite donc apporter doit prendre en compte toutes ces problématiques et surtout apporter une réponse à la complexité sous-jacente dee à l installation des ces outils. C est le logiciel Docker qui va me permettre de résoudre ce problème. Il va permettre une installation rapide et simplifiée des outils et une utilisation rapide Docker Docker est un logiciel open sources dont la première version est apparue en mars Ce logiciel automatise le déploiement d application au sein de conteneur logiciel. Il est né de plusieurs évolutions du monde numérique. Tout d abord, les entreprises aujourd hui tendent à ne plus avoir qu un unique logiciel monolithique, les micro-services sont de plus en plus courants. Les applications sont découplées 41

43 les unes des autres et le déploiement est rendu de plus en plus compliqué. Les environnements sont également de plus en plus complexes avec l augmentation de la demande et la nécessité d être disponibles en permanence. De cette situation découle une complexité que l on retrouve dans la matrice de l enfer dans laquelle on doit adapter l installation au couple applicatif/environnement[14]. L idée est alors venue aux concepteurs de Docker de se baser sur le principe de conteneurs utilisés pour transporter des marchandises dans le monde entier : un outil commun contenant n importe quel type de marchandises et surtout standard de manière à ce qu il soit manipulable facilement par tous. Grâce à ce fonctionnement, l application est installée dans un conteneur universel qui lui même est déposé sur n importe quel environnement qui gère les conteneurs. Les conteneurs sont comparables aux machines virtuelles[18]. L application installée dans le conteneur n a pas conscience de l existence de l hôte. Cependant, les machines virtuelles nécessitent la présence d un Hyperviseur qui va gérer le système virtuel. Deux systèmes d exploitation sont alors présents sur la machine : l hôte et le virtuel. Les conteneurs eux sont gérés nativement par le système hôte ce qui réduit la consommation de ressources à un seul système. Les conteneurs se basent sur des technologies qui font partie du noyau Linux et de son écosystème : LXC, BSD Jails, cgroups... Ce qu il apporte en plus est la standardisation des conteneurs afin qu ils soient facilement manipulables, transportables et accessibles via des outils simples. Les conteneurs peuvent maintenant être utilisés sur n importe quel serveur Linux possédant un noyau assez récent, qu il soit en machine virtuelle ou physique. Ils ne nécessitent aucune librairie externe supplémentaire ce qui simplifie grandement leur installation. La simplicité d utilisation et surtout de déploiement des conteneurs fait d eux les futurs objets qui seront produits et livrés sur l environnement de production et non plus une application nécessitant un environnement spécifique. Docker fonctionne avec une architecture client-serveur. Un démon est exécuté en tâche de fond et il va exposer une API. A la réception de requêtes sur ces API, il va effectuer une tâche en fonction de la requête. Le client Docker lui est celui qui va générer ces requêtes. C est un outil en ligne de commande qui va communiquer avec les API pour envoyer des ordres au démon Docker. Les conteneurs sont basés sur des images. Ces images sont des systèmes de fichiers, donc un ensemble de dossiers et de fichiers non éditables. Une image est donc un état figé d un système de fichiers. 42

44 Un conteneur, lui, utilise cette image comme point de départ mais possède son propre système de fichiers qu il peut éditer. Si nous prenons la comparaison avec des principes de la programmation orientée objets, les images sont les classes et les conteneurs sont les objets. Les images sont constituées de couches superposées les unes aux autres. Comme elles sont éditables, si nous souhaitons modifier une image, il nous faut rajouter une couche à l image contenant nos modifications. De nombreuses images sont disponibles sur le DockerHub[4] maintenu par l entreprise Docker Inc.. Parmi ces images, on retrouve une boîte à outil, la busybox, ainsi que de nombreuses distributions GNU/Linux, Debian, Ubuntu, CentOS, Fedora... Il est également possible d y déposer ses propres images et de les partager. Une fois sur le dépôt, elles peuvent être téléchargées et utilisées par d autres utilisateurs de Docker. Afin de rendre le partage plus facile, il est possible d utiliser un Dockerfile. Ce fichier va décrire les opérations à mener afin d obtenir une image définie. La première ligne va définir le point de départ de l image. C est en général une image présente sur le DockerHub ou maintenue par des entreprises en interne. Dans la suite du fichier, nous allons décrire les opérations à mener sur le système de fichiers pour obtenir notre image finale. Chaque utilisateur peut ainsi récupérer ce fichier et construire l image localement en assemblant l image de base et les modifications apportées. Une fois la construction terminée localement, il est possible de réaliser des conteneurs très rapidement. Docker permet une gestion assez poussée des accès réseaux aux conteneurs. Leur système de fichiers est innaccessible sans configuration depuis l hôte et de nombreuses applications nécessitent des accès à des ports spécifiques. Il est donc possible de lier les ports des conteneurs et les ports de la machine hôte afin de les rendre accessibles par l extérieur et par l hôte lui-même. [48][3] Docker-Compose L utilisation des Dockerfiles permet de gérer un conteneur avec facilité. Cependant, la gestion de plusieurs conteneurs en parallèle devient plus complexe. Dans notre solution, nous allons avoir besoin de plusieurs conteneurs pour accueillir tous les outils nécessaires aux processus d intégration continue. Pour cela nous allons utiliser Docker-Compose qui permet la gestion de multiples conteneurs. Il est issu 43

45 d une rachat du logiciel Fig qui faisait ces traitements auparavant. Docker-Compose est un petit outil développé par Docker Inc. mais externe à Docker qui permet la gestion de plusieurs conteneur à partir de leur Dockerfile. Pour cela il se base sur un fichier de configuration YAML. A son lancement, Docker- Compose va télécharger les images nécessaires, construire les conteneurs et les démarrer avec les options définies dans le fichier de configuration. Cet outil est publié sous forme d un script Python ou sous forme binaire. Une commande suffit à démarrer tous les conteneurs décrits dans le fichier de configuration. Ils peuvent être directement téléchargés depuis le DockerHub ou construits à partir d un Dockerfile. Le reste de la configuration est optionnelle. Chaque ligne est traduite en option pour la ligne de commande démarrant le conteneur Format de la solution Afin de répondre aux besoins des entreprises, je souhaite donc proposer une solution se basant sur Docker et Fig et permettant aux entreprises d expérimenter les processus d IC. La solution prendra la forme d un fichier de configuration Fig permettant le démarrage des Jenkins, Maven, SonarQube, Git et GitLab. Une documentation simple permettra de commencer un projet en utilisant ces outils. La documentation ainsi que le fichier de configuration seront publiés sur mon instance publique de GitLab à l adresse suivante : http :// Cette documentation présentera le worflow de processus d intégration continue simple permettant aux entreprises de les découvrir. Ils pourront être améliorés afin d optimiser leur fonctionnement et de les appliquer de manière plus spécifique aux projets cibles. Le seul prérequis de cette solution est de posséder une instance GNU/Linux avec un noyau dont la version est supérieur à En dessous de ce seuil, les noyaux de GNU/Linux ne possèdent pas toutes les fonctionnalités nécessaires à l utilisation de Docker. Une liste détaillée des distributions gérées est présente sur le site de Docker. 44

46 4 Conclusion A la suite de mes études en école supérieure d informatique, je me suis souvent posé la question de quel langage informatique était le plus performant pour que les développements soient efficaces et l application finale fiable. Après une première année de recherche et des stages dans de grandes entreprises, je me suis rendu compte que ce ne sont pas que les performances d un langage qui l imposaient aux entreprises. De nombreux facteurs entrent en compte dans le choix d un langage pour un projet. Les ressources disponibles tant humaines qu économiques influencent de manière importante ces choix. Au cours de mes stages j ai pu me rendre compte des problématiques récurrentes de développement logiciel, des problèmes de performances, de fonctionnement qui étaient commun à tous les langages. Ce ne sont donc pas les langages qu il faut mieux choisir pour améliorer la production d un logiciel mais la manière dont on va développer, c est à dire tous les processus mis en place autour du développement. J ai étudié les processus d intégration continue afin de déterminer leurs objectifs et leur possibilité d améliorer la productivité de projets de développement. L état de l art de ce document présente le fonctionnement et les intérêts de ces processus. Il souligne le fait que ces processus apportent une réelle valeur au projet en validant son fonctionnement à chaque étape du projet. Les environnements de production ne sont plus à craindre car les applications sont testées tout au long du développement. Tous les processus de l intégration continue ont pour objectifs d améliorer la qualité des développements et d assurer la continuité opérationnelle de l application. Un questionnaire m a permis de découvrir les raisons qui font que certaines entreprises d édition de logiciels n utilisent pas ces processus. Le manque de connaissance, le coût, la complexité et le temps nécessaire lors de la mise en place de ces processus sont les raisons qui ont émergé de l étude. Afin de répondre aux besoins des entreprises, j ai fait des recherches sur des outils fonctionnels, simples d utilisation et open sources. Finalement, la solution que je propose aux entreprises se compose de ce document de présentation de l intégration continue et un ensemble d outils facilement installables grâce à Docker. Cette solution permettra aux entreprises de mettre en place des processus d intégration continue pour leurs projets de développement logiciel. 45

47 Références [1] The Algol programming language. CIS/course.des/cis400/algol/algol.html. [2] CISQ Standards. [3] Docker Official Website. [4] DockerHub. [5] The features of C++ as a language. [6] Fig Official Website. [7] Git Official Website. [8] History of C++. [9] Internationel Organization for Standardization. home.html. [10] Introduction to C programming. cotter/page_03.htm". [11] Jenkins CI Official Website. [12] Mono Licensing. [13] Mono Official Website. [14] Paas : Present and future. paas-present-and-future/. [15] Plankalkül. Plankalkul.html. [16] SonarQube Official Website. [17] Sun acquisition by Oracle. acquisition_by_oracle. [18] What is Docker? [19] Les banques restent fidèles à Cobol. http: // lire-les-banques-restent-fideles-a-cobol-plus-performant-que-java html,

48 [20] Recherche d emploi par technologie. recherche-offre-emploi/annuaire-techno/, [21] G. Gregory O. Bazoud A. Cogoluègnes, T. Templier. Spring Batch in Action. Manning, [22] Adam Bard. Top Gihut languages for top-github-languages-for-2013-so-far/, [23] Frank Da Cruz. ENIAC. computinghistory/eniac.html. [24] Claude Delannoy. Programmer en Java. Eyrolles, [25] J-M Doudoux. Les bases du langage Java [26] Martin Fowler. Continuous Integration. articles/continuousintegration.html. [27] Patroklos P. Papapetrou G. Ann Campbell. SonarQube in Action. Manning, [28] Sylvain Gross. CSharp. Micro Application, [29] Ian Robinson Jim Webber, Savas Parastatidis. REST in Practice Hypermedia and Systems Architecture. O Reilly, [30] Bear Bibeault John Resig. Secrets of the JavaScript Ninja. Manning, [31] Langpop. Programming language popularity. october [32] R.G. Clark L.B. Wilson. Comparative Programming Languages. Addison- Wesley, [33] Patrick Longuet. Livre d or Java. Sybex, [34] Mike McQuaid. Git in Practice. Manning, [35] Pierre Mounier-Kuhn. Machine analytique de Babbage. universalis.fr/encyclopedie/machine-analytique-de-babbage/. [36] Science Museum. Ada Lovelace. babbage/adalovelace/. [37] Brian Napper. SSEM. html. 47

49 [38] Ronan PRESLE. Approfondissement technique : Intégration continue. approfondissement-technique-integration-continue/. [39] Dennis M. Ritchie. The development of the C language. bell-labs.com/who/dmr/chist.html, [40] Peter Van Roy. Une taxonomie des principaux paradigmes de programmation [41] J. Sklenar. Introduction to OOP in Simula. jskl1/talk.html, [42] John Ferguson Smart. Jenkins The definitive Guide. O Reilly, [43] Tiobe Software. Index d utlisation des langages. index.php/content/paperinfo/tpci/index.html, janvier [44] Srirangan. Apache Maven 3 Cookbook. Packt Publishing Open Source, [45] Srirangan. The Well-Grounded Java Developer. Manning, [46] Valentin Billotte Marc Thevenet. Le Langage CSharp. Micro Application, [47] David N. Welton. Programming language economics. it/articles/programming_language_economics.html, [48] Zenika. Formation docker. Technical report, Zenika, [49] Zenika. Formation intégration continue. Technical report, Zenika,

50 Glossary Ant Outil de configuration de construction de projets, principalement Java. API Ensemble de fonctions exposées par un logiciel et utilisables par un second logiciel distant. Assembleur Langage informatique bas niveau, c est à dire très proche du langage binaire de la machine. Il représente le langage machine sous forme de symboles. Bas niveau On dit qu un langage est bas niveau lorsqu il permet l accès aux fonctions proches du matériel et lorsque qu il se rapproche du langage machine. BCPL Basic Combined Programming Language, langage créé en 1966 pour être utilisé dans le développement de compilateurs pour les autres langages. Cobol Common Business-Oriented Language, langage utilisé principalement dans les domaines des affaires, de la finance, et de l administration. Code source Ensemble d instructions logiques exécuter par la suite par un ordinateur pour réaliser une tâche. Compilation Processus par lequel un code source va être transformer dans un format compréhensible par la machine, souvent binaire. Construction d une application Processus qui consiste à réaliser la compilation d une application et la mettre à disposition pour un déploiement. Docker Logiciel de gestion de conteneurs. Docker-Compose Logiciel de gestion de conteneurs multiples basé sur Docker remplaçant Fig. DockerHub Site de dépôt d images Docker. Déploiement Procédure d installation d une application dans son environnement de production cible. Dépôt de versions Système de fichier sur lequel un gestionnaire de version va centraliser les sources d une application, souvent situé sur un serveur distant. Développement Logiciel Activité d étudier, créer, améliorer et maintenir une application informatique à l aide de langages de développement. 49

51 Fig Logiciel de gestion de conteneurs multiples basé sur Docker maintenant Docker- Compose. Framework Bibliothèque de classes qui étend les capacités d une technologie. Gestionnaire de versions Outil utilisé en développement logiciel pour partager et historiser le code source d une application. GitHub Site de dépôt de code pour le développement logiciel basé sur le système de versionning Git. Gradle Outil de configuration de construction de projets, principalement Java, utilisant Groovy comme base de configuration. Grunt Outil de gestion de construction pour les projets JavaScript. Haut niveau On dit qu un langage est haut niveau lorsqu il permet de créer un programme sans tenir compte de la manière dont cela va être géré au niveau du matériel et qu il se rapproche du langage humain. Intégration Processus par lequel un développeur va ajouter le code qu il a modifié à la base de code commune d une application. Intégration Continue Ensemble de processus permettant la construction régulière d une application à partir de son code source pour vérifier son fonctionnement tout au long de son développement. Jacoco Java Code Coverage, outil utilisé pour étudier la couverture de code des tests. JavaScript Langage de scripts utilisé majoritairement côté client dans les navigateurs pour dynamiser les pages Web. Il est également utilisé côté serveur, pour le développeent de jeux et le développement mobile. Jenkins Serveur d intégration continue open sources. Langage Notation conventionnelle permettant de formuler des algorithmes logiques et de les faire exécuter par la machine. Langage Machine Ensemble de bits qui sera interprété par un ordinateur lors d un traitement informatique. Les langages de développement sont traduits ou compilés en langage machine pour être exécutés. 50

52 Lime Survey Application web open sources permettant la réalisation de questionnaires en ligne. Linux Système d exploitation basé sur Unix, libre et open sources. Logiciel Monolithique Logiciel dont toutes les parties sont réunies en une seule très grosse application, opposé aux micro-services. Machine Analytique Machine à calculer conçue par un mathématicien français, Charles Babbage en Programmable, elle symbolise l ancêtre de l ordinateur moderne[35]. MacOS X Système d exploitation basé sur Unix développé par l entreprise Apple Inc, créé pour être exécuté exclusivement sur les ordinateurs Mac. Maven Outil de configuration de construction de projets, principalement Java. Micro-service Logiciel dont toutes les parties sont individualisées afin de permettre des évolutions parallèles et rapides, opposé aux logiciels monolithiques. Novell Entreprise multinationale Américaine de développement de logiciels informatiques. Open Sources Modèle de production et de développement qui prône un accès universel via des licences libres et la possibilité de redistribuer tout ou partie du produit avec ou sans modification par un tiers. Paradigme Manière dont le langage va répondre à un problème posé. PHP Langage de scripts côté serveur utilisé pour le développement Web. Project Object Model (pom) Fichier de configuration XML des processus de Maven. Python Langage de développement haut niveau avec une syntaxe plus simple que le langage C. Qualité logicielle Indicateur permettant d évaluer la maintenabilité, la performance, la facilité de transfert entre deux équipes et la sécurité d un code source. Régression Etat dans lequel l implémentation d une nouvelle fonctionnalité rend inopérante une ancienne fonctionnalité de l application. 51

53 Serveur d intégration continue Outil complexe permettant la gestion de la récupération du code, de la construction, de l exécution des tests, de la gestion des résultats et des notifications. SonarQube Plateforme open sources d analyse de la qualité de code. Team Foundation Server Outil Microsoft pour la gestion d un projet avec notamment un gestionnaire de versions et des plugins pour les tâches de construction. Test Bloc de code ayant pour objectif de valider le fonctionnement d une partie de l application. Tierce Maintenance Applicative Fait de confier la maintenance et les évolutions d une application à un organisme tiers. Visual Basic Langage orienté événement de Microsoft basé sur la simplicité d apprentissage et d utilisation notamment en création d interfaces graphiques. 52