Intégration continue, un élément de la maîtrise du Time to Market
Intégration continue
Présentation du concept
Contrôler la qualité lors du développement d’un logiciel est un art difficile. Il est pourtant facile de s’assurer par exemple de l’absence de bugs par une écriture de batteries de tests couvrant les fonctionnalités requises. Reste que l’exécution de ceux-ci, l’assurance et la délivrance de leurs résultats relèvent d’opérations souvent longues et manuelles.
En sus de cela, contrôler la qualité intrinsèque du code écrit, analyser la présence de code dupliqué ou inutilisé, construire un livrable applicatif stable et complet sont des actions très coûteuses en ressources systèmes et ceci est d’autant plus vrai que le volume du code devient important.
Issue d’une des pratiques prônées par l’« Extreme Programming » (XP), l’Intégration Continue permet l’exécution périodique de scripts se basant sur une version du code source au sein d’un environnement dédiée et indépendant des postes de développement.
On pourra ainsi paralléliser la compilation, l’exécution des tests, l’analyse du code, la construction et le déploiement d’une application… sans bloquer l’avancée du développement de celle-ci.
Mise en contexte
Bien que l’intégration continue ne se confine pas nécessairement à l’utilisation d’XP, elle se doit d’être un composant omniprésent dans une activité de développement logicielle en particulier dans le cadre d’une méthodologie Agile.
En effet l’apport régulier de fonctionnalités dans le code se doit d’être en permanence validé et livrable à tout instant. Ainsi tout changement détecté dans une portion de code sera mis en concurrence avec l’intégralité du code applicatif et avec des standards de qualité, pour assurer la qualité du livrable en fin d’itération.
De plus, un des atouts majeurs de l’intégration continue est son influence sur l’implication d’une équipe de développement dans le cycle de vie global d’un projet. Ainsi, la mise à disposition du résultat en continue de l’exécution des tests et par exemple du taux de couverture du code par ces tests (code coverage) permettra d’intégrer complètement le test au processus de développement. Une équipe ainsi informée pourra être beaucoup plus attentive aux régressions qu’elle pourrait introduire dans le code, gagner en sérénité sur des refactoring ou optimisations du code, voire planifier facilement des déploiements applicatifs à période très courtes.
Aujourd’hui de nombreux éditeurs mettent en œuvre ce type d’outils :
LifeWare, application interne du Crédit Suisse, a été livrée tous les jours durant tout son cycle de développement,
Flicker, intègre une mise à jour de son site de production toutes les 30 minutes,
Google, déploie des tests en très grand nombre sur tous ses projets et utilise des outils d’IC pour notifier en permanence les résultats de ceux-ci
Se doter aujourd’hui d’une telle solution apparaît ainsi comme une étape indispensable dans la maîtrise du time to market.
Teamcity
Après plusieurs utilisations d’outils tels que Continuum ou Cruise Control sur de précédents projets, nous souhaitions focaliser notre solution d’intégration continue sur une solution plus robuste et performante.
La société JetBrains (http://www.jetbrains.com) éditrice du célèbre IntelliJ IDEA que nous utilisons intensivement par ailleurs, met à disposition d’une solution alliant performance, richesse fonctionnelle (dont certaines qui lui sont propres) et une grande interopérabilité : TeamCity.
Une architecture distribuée et multi plateformes
L’un des grandes forces de cet outil est son architecture distribuée. La solution est basée sur un seul serveur central communicant directement avec le système de gestion de sources (VCS) et « distribuant » à des agents dédiés l’ensemble des sources à prendre en compte.
L’intérêt d’une telle architecture réside évidemment dans sa capacité à pouvoir profiter d’une batterie de machines dédiées et réparties pour augmenter la puissance de traitement sous-jacente mais aussi de pouvoir valider la compatibilité d’une portion de code à un système donné.
Une intégration multi-environnements
TeamCity se démarque à nouveau sur sa capacité à s’intégrer dans de multiples environnements. Le fait de pouvoir déléguer l’exécution des projets à des Agents dédiés sur des plateformes ciblées, combiné avec la grande polyvalence de TeamCity en terme de support d’outillage existant (Ant, Maven, Intellij IDEA, Visual Studio, NAnt, …) amplifie considérablement son spectre d’utilisation.
On regrettera toutefois les limitations des outils d’analyse de code et/ou de recherche de duplication de code à des projets structurés sous IDEA. Le support de projets Maven2 est très jeune, et son utilisation ne nous a pas donné satisfaction, dans le sens ou le paramétrage des standards à analyser est très limité sur un projet Maven2.
A noter aussi qu’en terme d’intégration aux outils de gestion de sources (VCS), il offre la possibilité de s’intégrer aux standards du marché : Subversion, Perforce, CVS, SourceSafe, TFS… Le support de ceux-ci reste à pondérer avec les limitations qu’ils introduisent de par leur architecture. Ex : pas de transactions avec CVS, … Teamcity reste très clair et bien documenté sur les limitations intrinsèques de ces outils.
Le garant d’un code opérationnel…
L’une des fonctionnalités les plus intéressantes de TC est le « Pre-tested commit ». Cette possibilité permet aux développeurs de soumettre un ensemble de fichiers modifiés à TeamCity pour lui faire valider avant même de le soumettre au gestionnaire de source.
Ceci garantissant donc que le code soumis au VCS et donc aux autres membres de l’équipe reste opérationnel.
C’est sur ce genre de fonctions unique que TeamCity se démarque clairement sur ces concurrents et permettra la chasse aux « brokens-builds » et au contraire garantir la sérénité sur le commit de son code vis-à-vis du reste de l’équipe de développement.
… et propre
La capacité d’un code à se conformer aux standards que l’on se donne sur son écriture est une opération souvent longue et très coûteuse en ressources systèmes. En effet, au-delà des traditionnelles vérifications de style, c’est l’analyse de règles plus élaborées comme la complexité des méthodes ou des classes, la recherche de bugs probables, d’incohérences entre des fichiers de traduction qui demandent un traitement de l’ensemble des fichiers sources au travers d’algorithmes parfois évolués. Ce travail fournit une assurance supplémentaire sur la disposition du code à être maintenu et remanier pendant une longue période.
Pour ce faire, TeamCity utilise pleinement parti des capacités de l’IDE de Jetbrains, Intellij IDEA pour mettre en concurrence le code d’une application dans sa globalité (Code Java, fichiers de configuration XML, code HTML et JavaScript, feuilles de style CSS… ) avec des règles définis au sein de cet IDE.
Le rapport généré met l’accent sur les différences introduites dans le jeu de sources modifiées, en laissant toutefois la possibilité de visualiser l’ensemble des violations des règles. Ces « fautes » sont associées au code qui les concerne et structurées de manière hiérarchique pour faciliter leur corrections.
De même pour les analyses de duplication de code. TeamCity analyse dans sa globalité chaque portion de code (en utilisant à nouveau une fonctionnalité d’IDEA) pour le mettre en parallèle d’autres éléments de code. Le résultat est amené de manière assez intelligente en montrant le coût impliqué par chaque duplication, ainsi que leur nombre et les deux portions de codes incriminés.
La contrepartie est que ces fonctionnalités se cantonnent à un projet sous IDEA, comme précisé plus haut le support Maven2 reste surfacique. Il n’est pas possible de définir un scope précis des sources a analyser ou le jeu de règle à passer sur ce type de projet.
Une productivité dans la mise en œuvre des projets
Après avoir utilisé d'autres systèmes d'intégration, on apprécie la facilité de mise en oeuvre de projets d'intégration continue sous Team City. Une fois le produit installé, l'ensemble des opérations de paramétrage s'effectue depuis une interface ergonomique et performante. Pour peu que le script de départ soit correctement écrit, sans faire de référence au système de fichier du développeur par exemple, le démarrage d'un nouveau script n'est l'affaire que de quelques minutes.
De plus, TeamCity offre une réelle plus value en insérant ses propres fonctionnalités au sein de scripts existant. Ainsi, la mise en oeuvre de la couverture des tests pour les script ant ne demande que de cocher une option dans le lancement du script. A l'exécution, TeamCity identifie les opérations de compilation et l'emplacement des fichiers compilés pour instrumenter automatiquement le code en vue du suivi de la couverture des tests. Après exécution, un nouveau rapport est proposé affichant le pourcentage de code testé par package et par classe ainsi que le surlignage des lignes testées ou non directement dans le code source.
Des feedbacks soignées et instantanées
TeamCity enregistre toutes les opérations qu’il déclenche ainsi que tout les événements s’y attachant (logs, temps consommé, jeu de sources concerné, …).
On retrouvera par exemple pour une phase d’exécution des tests des rapports détaillés permettant une visualisation instantanée des tests en échec, une synthèse par projet des tests en échec récurrents, des statistiques sur l’exécution d’un type de projet (Succes Rate, Build Duration, …).
De plus il s’intègre parfaitement dans les outils de communication d’aujourd’hui pour notifier les équipes de développement. Outre le mail, il est à même d’informer n’importe quel utilisateur par chat (Jabber, IRC,…), par flux RSS ou par le biais d’un plugin dédié installé soit dans l’OS (Windows/Linux/Mc OS) soit directement dans l’IDE (IDEA, eclipse, VisualStudio).
On regrettera à nouveau la nette différence de la version IDEA de ce plugin par rapport aux autres, privant ces derniers de certaines des fonctionnalités, comme le « Remote Run » depuis l’IDE directement.
Un système de Licence adapté
TeamCity est distribué sous une licence professionnelle gratuite permettant une utilisation limitée à 20 projets de configurations, 20 utilisateurs et 3 agents. Malgré un support limité sur les systèmes d’authentification utilisateur : pas de LDAP, cette licence permettra une utilisation à coût limité pour des projets de moyenne envergure.
La licence Enterprise ne contenant aucune limitation sur les fonctionnalités présentes vous en coûtera 1999$ + 299$ par agent.
On notera enfin l’effort certain de JetBrains pour soutenir la communauté qui les soutient en offrant ce produit aux projets OpenSource.
Conclusion
Au sein d’ITIntegrans, le choix de TeamCity nous a apporté un vrai plus. Cependant la présence de différentes limitations ou anomalies dans son fonctionnement comme par exemple l'absence de gestion (pour le moment) de code coverage sur des projets gérés avec Maven, une gestion de la priorité sur les Builds déclenchés par dépendances de construction de projets, nous ont obligés à adapter certains de nos scripts pour pallier à ces problèmes.
Ces modifications restent minimes et la réactivité dont fait preuve JetBrains sur ce genre d’améliorations nous amène pleine confiance et satisfaction sur cette solution.
De plus le produit reste d'une très grande stabilité, doté d'une interface full Web 2.0 permettant une configuration très rapide et intuitive de configurations qui peuvent être assez complexe. Si on ajoute à cela une licence pro gratuite, une documentation très fournie ce choix reste -et de loin- un atout majeur dans notre activité de développement agile.
Reste que l’utilisation d’un tel produit nécessite une bonne montée en compétence qui pourra être très fortement raccourcie par l'intervention d'un spécialiste du produit.
