Source image : Abstract vector created by vectorjuice – www.freepik.com
L’intégration continue est un ensemble de pratiques permettant de tester de manière automatisée chaque révision de code. Elle est devenue une composante essentielle dans un environnement de développement agile. A chaque changement de code effectué par un membre de l’équipe, celui-ci est intégré à un référentiel centralisé pour donner suite à une série de tests qui sont automatiquement menés. Ces tests permettent de garantir la qualité du code.
Un outil s’intégrant particulièrement bien dans la mise en oeuvre de l’intégration continue (CI : Continuous Integration) est Jenkins.
Besoin d'un accompagnement dans vos développements?
Jenkins : L’outil de CI open source de référence ?
Jenkins est un nom de famille originaire d’Angleterre mais devenu populaire dans le sud du Pays de Galles. Le terme « Jenkin » signifiait initialement « petit John » ou « fils de John ». Le suffixe « -ki(j)n » provient du néerlandais et s’est popularisé en Angleterre. Le « s » final fut ajouté par la suite pour signifier « fils d’un Jenkin ».
Outil d’intégration continue, Jenkins est une application open source conçue pour orchestrer des tâches informatisées liées aux builds, aux tests et aux déploiements. C’est un des outils open source les plus utilisés dans la mise en place des CI.
Historiquement Jenkins a été créé en été 2004 par « Kohsuke Kawaguchi » lorsqu’il travaillait à « Sun Microsystems ». A l’origine il s’appelait Hudson et la première release a eu lieu en février 2005.
En général, on utilise Jenkins dans un « conteneur web » ou « conteneur de servlets » comme Java SAS. Jenkins fédère une vaste communauté qui propose régulièrement de nouvelles améliorations du service. Il est assez simple à installer et propose pas moins de 1500 plugins, permettant ainsi de l’intégrer à la plupart des outils de développement, de test et de déploiement.
Jenkins s’intègre à pratiquement tous les outils de la chaîne d’outils d’intégration continue (CI : Continuous Integration) et de livraison continue. (CD : Continuous Delivery)
Exemple d’utilisation de Jenkins dans une intégration continue(CI)
L’intégration continue prend sa source par la validation d’un changement de code dans un référentiel centralisé comme SVN, GIT ou encore TFS.
Nous utilisons dans notre exemple Tortoise SVN qui est un logiciel client de SVN et qui fait partie des plus populaires. C’est un logiciel de gestion de version libre, distribué selon les termes de la licence GNU GPL, sous forme de plugin pour Microsoft Windows. Il constitue une extension conçue pour Windows Explorer.
Chaque fois que l’on poste du code (COMMIT effectué par le développeur) sur SVN (scrutation de svn), l’intégration continue réalise les étapes suivantes:
Dans notre exemple, comme notre solution comporte plusieurs composants écrits dans des langages différents, nous avons fait le choix de la compilation des programmes en .Net, Delphi10 et Delphi7 sur différentes machines en ligne de commande dotnet msbuild , dcc32.exe monProjet.dpr.
Pour répondre à cette problématique Jenkins peut être configuré pour utiliser une stratégie maitre / esclave.
En fin de traitement, un rapport est envoyé par mail et le tableau de bord dans Teams est mis à jour à l’attention des équipes.
Ainsi, les équipes sont informées en temps réel si un problème est survenu ou si la version est déployée sur la plateforme d’intégration. Elle peut ensuite démarrer la phase de qualification d’une version.
Passons au déploiement
L’étape de déploiement est la suite de l’intégration continue. Elle permet la construction du package pour mise en production.
Le mode Debug et le mode Release sont des configurations particulières pour construire votre projet. Les programmeurs utilisent généralement le mode Debug pour suivre pas à pas le déroulement du programme. Le mode Debug n’optimise pas la compilation de façon binaire. Le mode Release est nécessaire pour l’étape de mise en production.
Dans notre exemple, cette étape se construit de la façon suivante :
Le packaging comprend un script PowerShell de mise en zip et de mise à disposition du zip sur le serveur de déploiement.
La notification prend en charge la création d’une nouvelle version sous JIRA, le déplacement des tickets JIRA d’un état « Validé » à un état « Livrés pour Test », ainsi que l’avertissement des équipes avec Teams. Jira est un système de suivi de bugs, de gestion des incidents et de gestion de projets développé par Atlassian et publié pour la première fois en 2002.
L’intégration continue est un bon premier pas vers le déploiement continu qui est de livrer chaque modification apportée au logiciel directement aux utilisateurs finaux. Elle est de plus en plus utilisée en entreprise afin de livrer toujours plus vite de la valeur à l’utilisateur final tout en garantissant la qualité du code et du produit final.
Vous recherchez des informations complémentaires ? Nos équipes restent à votre écoute, n’hésitez pas à nous contacter dès aujourd’hui.
Article proposé par
Pierre-Olivier Wolff
Programmeur