Vous êtes CTO ou développeur et soucieux de livrer de la qualité tout en restant productif ? C’est possible ! La mise en place d’une plateforme d’intégration continue (PIC) est un excellent début à cela.
Dans cet article, je vais essayer de vous faire mon retour d’expérience sur l’intégration continue, telle que j’ai eu l’occasion de la mettre en place ou vécue sur des projets de toute taille.
Décrite maintes-fois et mise en place depuis de nombreuses années, l’intégration continue évolue constamment.
Au départ, l’intégration continue se cantonnait à compiler de façon régulière du code afin de valider son bon fonctionnement. De cette façon, l’ajout de code au gestionnaire de sources (Git, ou SVN à défaut) se fait sur de petits changements validés par toute une chaîne et sur lesquels les développeurs ont plus rapidement du feedback.
L’intégration continue intègre les tests; qu’ils soient unitaires, d’intégration, end-to-end, etc. mais également des outils d’analyse de code, tels que SonarQube. Tous les tests sont joués et tout test en échec bloque le processus. Des remontées bloquantes ou majeures de SonarQube peuvent également bloquer le processus.
Une chaîne d’intégration continue classique est composée de plusieurs étapes automatisées :
Je recommande fortement que la chaîne d’intégration continue se mette en marche après toute soumission de code.
Néanmoins, sur certaines applications legacy, la construction des artifacts (le build) peut prendre plusieurs heures et il devient dès lors plus compliqué de déclencher toute la suite de façon systématique.
D’expérience, quand la plateforme d’intégration continue est mise en place tardivement sur un projet, il est plus compliqué de la rendre systématique. On aura alors recours à divers procédés pour gagner du temps : plus de traitements en parallèle, l’utilisation d’images Docker rapides à mettre en place, etc.
Afin d’éviter d’en arriver là, je conseille de mettre en place une plateforme d’intégration continue dès que possible dans tout projet et de la surveiller. Une architecture de type micro-services permet de garder une taille d’application raisonnable et donc de minimiser les temps requis à construire, valider et déployer.
Au sein d’une équipe, disposer d’une PIC, c’est garantir que toute modification de code ait traversé les mêmes étapes. Nous minimisons ainsi les risques de défaillance, même si le risque zéro n’existe pas encore.
Un des objectifs est d’automatiser les tâches répétitives à faible valeur ajoutée, ce qui permet à l’équipe de développement de dégager davantage de temps et à se consacrer au côté fonctionnel et créatif.
Pour aller encore plus loin dans l’automatisation, il est possible d’étendre l’intégration continue avec du déploiement automatisé sur les environnements de développement ou de démo. Il est rapidement plus rentable de passer quelques heures à mettre en place un système de déploiement automatisé plutôt que de le faire manuellement en quelques minutes régulièrement.
L’objectif ultime serait de déployer l’application en production de façon totalement automatique, mais cela nécessite la mise en place d’une couche supplémentaire : les tests d’acceptation, validés sur un environnement de qualification iso-prod. On parle alors de déploiement continu.
Ainsi, sur l’une de mes missions, le déploiement sur l’environnement de développement se faisait suite à chaque modification de la branche master, après avoir traversé toutes les étapes de validation. À la fin du sprint, l’application était livrée sur l’environnement de démo via un simple clic dans une interface (GitLab).
Pour obtenir une application de qualité, il est indispensable d’obtenir des retours de la production aussi souvent que possible.
C’est notamment l’objectif de l’approche DevOps.
Cette pratique culturelle permet de mettre l’accent sur l’agilité et sur des cycles courts de livraison, particulièrement adaptée dans une approche Agile/Scrum.
L’approche DevOps permet d’améliorer la qualité de l’application en redonnant une partie de la responsabilité du déploiement et d’exploitation à l’équipe de développement, plus à même d’intervenir rapidement et efficacement.
Prenons l’image d’un restaurant : À qui feriez-vous le plus confiance pour vous donner la liste des ingrédients utilisés à la confection d’un plat ? Au cuisinier, ou au serveur ? En revanche, le serveur est le plus à même à recueillir la commande, à servir la bonne personne. Son rôle ne peut pas être mis de côté.
C’est l’équipe de développement qui sait de quoi est constituée l’application, comment elle fonctionne, de quoi elle a besoin. L’équipe opérationnelle ne devrait pas être une frontière imperméable aux remontées utilisateurs.
Il est indispensable de renforcer les liens entre développeurs et opérationnels au plus tôt du cycle de vie de l’application.
L’approche DevOps, c’est bien plus que de renforcer les liens entre l’équipe de développement et l’équipe opérationnelle, c’est aussi retirer les silos traditionnels entre chaque spécialité et permettre à chacun de collaborer plus étroitement, de renforcer la communication, etc.
De ce fait, l’approche permet de réduire :
Bien que l’approche DevOps n’inclue pas la plateforme d’intégration continue, une synergie positive se dégage de la mise en place de ces deux pratiques.
Pour être efficace, il faut bien s’outiller, c’est-à-dire mettre à disposition les bons outils et les utiliser systématiquement. Par bons outils, j’entends des outils adaptés à l’équipe et au contexte. GitLab, avec la surcouche GitLab-CI me paraît particulièrement adapté, mais d’autres peuvent également faire l’affaire.
Attention, l’excès d’outils nuit à la bonne productivité. Ils doivent être maintenables, robustes et stables.
Les liens inter-outils apportent un réel plus dans cette plateforme. Il est par exemple possible de faire figurer les anomalies SonarQube sur GitLab, qui sont alors inclus dans une demande de merge.
Faîtes profiter les autres équipes en partageant votre PIC ! Cette PIC évolue et dans un contexte agile il est fréquent de revenir dessus pour l’affiner, ajouter des règles et vérifications.
Le facteur humain ne doit pas être sous-estimé. La mise en place d’une plateforme d’intégration continue doit se faire en accompagnant les développeurs au changement, surtout s’il s’agit d’une équipe qui n’a jamais fonctionné avec.
C’est un enseignement que j’ai pu tirer suite à l’une de mes missions, alors que mon rôle était de mettre en place une plateforme d’intégration continue dans une équipe qui n’utilisait même pas encore de gestionnaire de dépendances.
Afin de maximiser les chances de réussir, il faut au minimum :
La PIC m’a changé la vie, et vous, qu’en pensez-vous ? De quoi se compose votre PIC ? Quels sont les limitations que vous rencontrez ?
Gérer les branches en utilisant le GitLab Flow Plugin SonarQube pour remonter les anomalies sur GitLab, développé par un collègue
