L’intégration continue (I.C.), la livraison continue (L.C.) et le déploiement continu (D.C.) sont des notions souvent confondues avec l’Agilité ou le Devops et mal comprises.
L’I.C., la L.C. et le D.C. sont des pratiques démocratisées avec l’Agilité et le DevOps, bien que certaines de celles-ci soient adaptées/recommandées à tout logiciel développé et plus particulièrement avec des méthodes incrémentales. Les bonnes pratiques comme l’intégration fréquente du nouveau code, les tests précoces, l’automatisation des tâches répétitives ou la standardisation des projets devraient être obligatoires, peu importe la méthode de gestion du projet.
Les pratiques de l’I.C., de la L.C. et du D.C. sont mises en œuvre par un ensemble d’outils qui déclenchent une suite d’actions automatiques. C’est pour cela qu’on associe les termes de « chaîne outillée » et de « pipeline » à l’I.C. et ses extensions.
- Définition de l’Intégration continue, la Livraison continue et le Déploiement continu
Intégration Continue :
L’intégration Continue (I.C.) consiste à intégrer les branches de développement au code source d’une application le plus tôt et le plus fréquemment possible (plusieurs fois par jour) lors du cycle de développement.
On utilise pour cela un logiciel de gestion de versions et des flux de travail de branche adaptés, qui isolent les développements dans des branches de fonctionnalité. Les branches de fonctionnalités sont ensuite fusionnées au code source commun, via des demandes de fusion.
L’I.C. automatise des tests dont le rôle est de vérifier, à chaque modification du code source, que le résultat des modifications ne produit pas de régression visible au niveau du code, dans l’application développée, et que les nouvelles fonctionnalités sont implémentées correctement.
L’I.C. automatise aussi les étapes de construction du code qui contiennent les commandes nécessaires à la création d’un binaire installable de l’application (compilation). L’étape de construction peut aussi contenir la création automatique de documentation, l’enrichissement du journal de changement ou tout autre élément qui pourrait être généré automatiquement à ce stade.
L’ensemble de ces actions automatiques doivent être exécutées le plus souvent possible, sans pour autant nuire au temps d’exécution de l’ensemble des actions. Il s’agit donc de trouver à quel moment déclencher chacune des actions au sein des différentes phases du flux de travail.
Enfin, dans la plupart des flux de travail, une dernière action (création d’un tag, création d’une branche, fusion vers une branche de production…) permet de créer une version de l’application (Livraison Continue). Dans le cas du Déploiement Continu, cette action peut déclencher la mise en production automatique de cette version de l’application.
Chaque étape du flux de travail déclenche différentes étapes du processus d’Intégration Continue.
L’Intégration Continue automatise l’étape de « build » et certains tests.
Les tests vérifieront que chaque modification sur le code source ne produit pas de régression repérable par ces derniers dans l’application développée et que les nouvelles fonctionnalités sont implémentées correctement. Ils peuvent inclure les Tests unitaires (TU), des checkstyle, des tests d’intégration, le respect des bonnes pratiques, des audits de sécurité automatique…
La phase de build automatise la compilation du code et le packaging, c’est à dire toutes les étapes requises pour que le code soit mis à disposition en tant qu’artefact déployable (aussi appelé objet binaire) sur les différents environnements.
Livraison Continue :
La Livraison Continue est une extension de l’Intégration Continue dans laquelle les artefacts créés sont automatiquement versionnés et livrés (ou facilement livrables, via un click, par exemple) dans un gestionnaire de dépôt d’objets binaires. L’application peut alors à tout moment être déployée par les membres des équipes d’opération (Ops) sur l’environnement de leur choix.
C’est l’équivalent de la construction du « .exe » pour un logiciel windows, du « .jar »pour un logiciel java ou de l’« apk » pour une application Android.
A ce stade, le déploiement des environnements de qualification ou de pré-production peut aussi être automatisé.
Déploiement Continu :
Le Déploiement Continu permet le déploiement automatique de chaque nouvelle version du code sur l’environnement de production avec un impact client immédiat. C’est donc une extension de la Livraison Continue sans qu’une action manuelle des Opérationnels (ou « Ops » de DevOps) soit requise pour la mise en production.
Le Déploiement Continu implique des méthodes de déploiement automatisées qui s’appuient généralement sur des logiciels de gestion de configuration.
Il implique, dans la majorité des cas, un niveau de test automatisé avancé à tous les niveaux de la chaîne outillée (tests unitaires, tests d’intégration, test de sécurité, les tests de charge, test d’IHM, analyse de qualité…).
Enfin, il faudra prendre en compte des contraintes administratives liées à la gestion des changements, qui, selon les entreprises, auront plus ou moins de propension à accepter le D.C.
On peut facilement traduire ces définitions par ce schéma :
- L’importance de l’Intégration Continue, de la Livraison Continue et du Déploiement Continu en agilité
L’I.C., la L.C. et le D.C. représentent un excellent choix d’outil dans la mise en œuvre de à l’Agilité.
La qualité est essentielle en Agile. En testant systématiquement et fréquemment tous les ajouts au code source, on détecte au plus tôt les anomalies. Une bonne chaîne outillée d’I.C. automatise aussi des étapes d’audit de qualité du code (détection du code en doublon et des mauvaises pratiques) et de sécurité (recherche des failles connues). On assure donc une qualité optimale du produit. Produit qui sert de base pour tous les futurs développements.
De plus, l’agilité prône des livraisons régulières de produits utilisables et fonctionnels. L’Intégration Continue et ses dérivées permettent de proposer ces livraisons régulières par le fait de fusionner les développements au code source plusieurs fois par jour et d’automatiser la construction des binaires et les tests. Dans la Livraison Continue et le Déploiement Continu, on rend même possible le déploiement de ces développements en production dans un délai très court, pouvant être de quelques minutes. Cela accroît la rapidité à laquelle les équipes de développement peuvent s’adapter au changement et aux demandes des clients.
La conséquence recherchée est une baisse considérable du temps de mise sur le marché d’une nouvelle fonctionnalité.
Enfin, l’agilité encourage la communication et le travail avec des équipes pluridisciplinaires. Les chaines d’Intégration, de Livraison ou de Déploiement Continus vont dans ce sens car elles utilisent des outils communs qui centralisent les développements, les tests, la construction de code, les déploiements, la documentation, et souvent aussi l’aspect gestion de projet clairement orienté Agile (tableau agile, gestion des sprints, tableaux « burndown », « product backlog », gestion de la complexité…).
L’utilisation des mêmes outils par les développeurs, les testeurs et les Ops crée des interactions fortes entre tous les acteurs. Dans ce contexte, tout le monde peut se retrouver à développer un script participant à l’automatisation, tout le monde doit également prendre en compte les contraintes liées à la production ; dans la veine de l’Agilité et du DevOps.
- La nécessité de l’automatisation des tests
Vous l’avez compris, il n’existe pas de chaîne d’Intégration, de Livraison ou de Déploiement Continus digne de ce nom sans tests.
Les tests associés à ces chaînes sont donc exécutés très fréquemment, à chaque commit, ce qui peut revenir à plusieurs fois par jour ! Cette intensité d’exécution des tests ne peut pas être soutenue par des tests manuels et des testeurs pour 2 raisons principales :
- Le temps d’exécution est beaucoup trop long
- Aucun testeur ne souhaite exécuter plusieurs fois par jours pendant des mois les mêmes tests !
Pour se rendre compte de l’intensité de la fréquence d’exécution des tests, on peut utiliser cette image :
- Quels tests à quel moment et pour quelle pratique ?
Comme décrit avec l’image de la première partie, l’Intégration Continue au sens large (I.C., L.C., D.C.) est indissociable des tests. Chaque niveau d’intégration engendre des tests (ou familles de tests) à ajouter.
Pour rappel, les tests dépendent du contexte. En fonction de l’impact des changements, différents types ou familles de tests sont nécessaires.
Comme vu au chapitre précédent, l’automatisation des tests est indispensable avec les chaînes d’Intégration Continue, les tests manuels atteignant très vite leurs limites en provoquant des interruptions dans le pipeline d’Intégration Continue qui est justement censé être continu !
Néanmoins, automatiser ses tests ne veut pas dire automatiser tous ses tests. Dans le cadre de l’intégration Continue, les utilisateurs finaux du produit ne sont pas impactés à chaque commit de code sur une branche de développement ou à chaque fusion (merge) de branche sur le code source. Dès lors, les tests nécessaires sont les tests utiles aux développeurs, à savoir les de tests unitaires et les tests d’audit de qualité réalisés par des logiciels comme Sonarqube ou des tests de sécurité pouvant être réalisés par Fortify, par exemple. Idéalement, on automatisera aussi les tests d’intégration dès ce stade.
Dans le cas d’un impact client, il faut pouvoir assurer une qualité minimale lors de l’utilisation de l’application. Dans ce contexte qui est celui du Déploiement Continu, il faut automatiser les tests d’intégration et les tests de validation pouvant inclure, selon la nature du logiciel, des tests d’interface graphique, des test de sécurité, des tests non fonctionnels, des tests de performance…
Pour mettre en œuvre ces différents types de test, les chaînes de Déploiement Continu s’appuient généralement sur les environnements de qualification/pré-production, et sur la conteneurisation (Docker) pour reproduire un contexte le plus proche possible de la production.
Enfin, entre l’Intégration Continue et le Déploiement Continu, il y a la Livraison Continue. La lLvraison Continue doit proposer un « package » installable de l’application. Il existe donc un type de test particulièrement important pour la livraison, c’est le test « d’installabilité ». Il est nécessaire de s’assurer que le « package » créé soit installable et utilisable sur l’ensemble des environnements ciblés. Si ce n’est pas le cas, la Livraison Continue perd tout son sens. C’est également à ce moment que l’automatisation des tests d’intégration n’est plus une option mais une nécessité.
On peut donc résumer les besoins en test avec cette image (chaque nouveau niveau nécessitant les solutions des niveaux précédents) :
- Exemple de chaîne d’Intégration Continue
CODE :
Développement des nouvelles fonctionnalités sur des branches de fonctionnalité. Fusion des branches de fonctionnalité sur une branche commune contenant le code source de l’application. Dans la majorité des cas, on utilisera l’incontournable Git en tant que gestionnaire de version. Le nombre, le nom des branches et la façon dont on les utilise peuvent changer en fonction du flux de travail utilisé. Le choix du flux de travail est primordial dans l’automatisation car il détermine à quel moment les différentes étapes du pipeline sont lancées. On peut citer GitFlow et GitlabFlow comme flux de travail adapté.
TESTS UNITAIRES et AUDIT DE CODE (automatisé dans l’I.C.) :
Déclenchement des tests unitaires et de l’analyse de qualité avec des outils comme Sonarqube. Les tests unitaires peuvent même être effectués dès qu’un commit est fait sur une branche de fonctionnalité, avant la fusion sur le code source. Tout est une question d’équilibre entre temps d’exécution d’un pipeline et fréquence de déclenchement de celui-ci.
CONSTRUCTION (automatisé dans l’I.C.):
Le code est compilé et conditionné en une version de binaire installable (un paquet debian, un .jar, une image docker ou n’importe quel autre format suivant le type de projet). Il est fortement recommandé de générer aussi la documentation, la release note ou tout autre élément nécessaire à la création d’une nouvelle version de l’application. Généralement, cette nouvelle version est créée via un tag sur la branche contenant le code source, mais cela dépend du flux de travail utilisé.
LIVRAISON (automatisé dans la L.C.) :
La nouvelle version du binaire créée dans l’étape précédente est envoyée dans un dépôt d’objets binaire comme Artifactory ou Nexus. Le binaire est à présent téléchargeable et installable sur les différents environnements dont la production.
TESTS D’installabilité et D’INTEGRATION (automatisé dans le D.C.) :
Tests d’installabilité des binaires et tests d’intégration sur un environnement le plus proche possible de la production.
DEPLOIEMENT des environnements pré-production (automatisé dans le D.C.) :
La nouvelle version du binaire est déployée sur l’environnement de qualification. On utilise idéalement un gestionnaire de configuration tel que Chef ou Ansible pour industrialiser les déploiements sur l’infrastructure et permettre le déploiement en un clic.
TESTS DE VALIDATION (IHM, non fonctionnels, sécurité) (automatisé dans le D.C.) :
Tests de validation, aussi poussés et divers que peuvent le nécessiter le produit ou la politique de l’entreprise.
DEPLOIEMENT EN PRODUCTION (automatisé dans le D.C.) :
Le binaire est enfin déployé en production de la même façon que sur les environnements précédents.
A propos du co-auteur: Mickaël CARLIN
Ingénieur DevOps, mon rôle est de réfléchir, mettre en place et faire évoluer des chaînes outillées d’Intégration, Livraison et Déploiement Continus chez nos clients. Il s’agit d’un double travail humain et technique, puisqu’il faut mettre en place l’environnement technique en s’adaptant aux besoins du client mais aussi apporter de nouvelles façons de travailler, former et accompagner les équipes dans le changement.
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
