Intégration Continue (Continuous Integration)

Qu’est-ce que l’intégration continue ?

L’intégration continue (CI) peut être considérée comme une alternative au feature branching. En termes simples, ce processus se produit lorsque les équipes intègrent leurs codes de manière continue dans une branche partagée ou une ligne principale, ce qui permet d’obtenir des retours instantanés.

Dans ce cas, le trunk-based development permet l’intégration continue. En d’autres termes, il offre aux équipes la possibilité de fusionner de petits changements plus fréquemment dans la base de code principale ou trunk, potentiellement plusieurs fois par jour. Le trunk-based development permet aux développeurs de diviser leur travail en petits lots, puis de fusionner leur travail dans le trunk ou la ligne principale au moins une fois par jour. En revanche, le feature branching peut nécessiter des jours ou des semaines de travail, car les développeurs effectuent des modifications sur des branches longues qui ne sont fusionnées qu’une fois la fonctionnalité terminée.

L’automatisation des builds est l’un des prérequis majeurs pour l’intégration continue. Chaque intégration effectuée par un développeur est vérifiée par un build automatisé pour détecter d’éventuelles erreurs. Un outil de build gérera donc la livraison du logiciel de manière automatisée. En d’autres termes, chaque commit effectué par un développeur doit déclencher une série de tests automatisés pour garantir la qualité du code. Ces tests automatisés doivent indiquer si le logiciel fonctionne comme prévu. Il existe une variété d’outils parmi lesquels choisir, en fonction de vos besoins, notamment Jenkins, Travis CI, Circle CI, TeamCity et CodeShip.

Avantages de l’intégration continue

Déploiement plus rapide

Cette technique permet aux développeurs d’avancer rapidement. Contrairement aux feature branches, la branche principale dans le trunk-based development est la seule branche de longue durée, tandis que toutes les autres branches ont une durée de vie limitée, ce qui réduit les conflits de fusion, car aucune branche ne reste en développement trop longtemps. Cela permet également d’obtenir des retours presque immédiats, augmentant ainsi la transparence entre les développeurs, au lieu d’attendre des semaines que les modifications d’une branche privée soient intégrées.

Réduction des risques

Lorsque les développeurs intègrent continuellement leurs modifications dans la ligne principale, il devient beaucoup plus facile et rapide de détecter et de corriger les bogues. Cela augmente les chances de publier une fonctionnalité plus stable avec moins de bogues, ce qui améliore considérablement le produit, toujours prêt à être publié. Cela réduit également le risque de fusionner des branches longues qui donnent lieu à des conflits, ce que l’on appelle le « merge hell ».

Publications de meilleure qualité

L’intégration continue est essentielle pour publier rapidement de nouvelles fonctionnalités et effectuer de petits changements, tout en aidant à minimiser le « merge hell » souvent causé par des branches longues. Comme mentionné précédemment, avec l’intégration continue, les bogues peuvent être détectés beaucoup plus rapidement grâce aux changements continus, ce qui se traduit par une efficacité et une productivité accrues.

Cela signifie que la qualité est considérablement améliorée, car les modifications sont continuellement effectuées et vous n’attendez pas que tout le monde ait terminé pour intégrer vos modifications, ce qui vous permet de vérifier votre code plus fréquemment et d’avoir plus de confiance lors de la publication de nouvelles fonctionnalités.

Inconvénients de l’intégration continue

Le principal défi de cette pratique réside dans le fait que, en raison des modifications fréquentes, les développeurs peuvent se marcher sur les pieds lorsqu’ils essaient d’intégrer leur code en même temps, ce qui peut entraîner des temps d’attente plus longs. Cette pratique nécessite également une surveillance constante pour résoudre rapidement tout problème qui pourrait survenir. Néanmoins, elle reste très utile lorsque vous cherchez à publier de nouveaux produits rapidement et en toute sécurité.

Intégration continue et livraison continue vs déploiement continu

Les termes intégration continue et livraison continue sont souvent utilisés ensemble. En fait, les deux vont de pair et sont souvent désignés ensemble par « CI/CD ».

Pour que la livraison continue ait lieu, vous avez besoin de l’intégration continue. La livraison continue permet ensuite la livraison automatisée du code intégré depuis l’étape de développement jusqu’à la production.

Avec la livraison continue, vous préparez la publication pour une livraison fréquente, le code étant livré plusieurs fois par jour. Elle consiste à tester le code et à s’assurer qu’il est livré sans bogues ni retards, en partageant les modifications avec un groupe d’utilisateurs sélectionnés pour obtenir leurs retours avant de les publier à tous les utilisateurs.

Le CI/CD représente donc le processus de développement, de test et de livraison continue de nouvelles versions.

La dernière étape du CI/CD est le déploiement continu, souvent confondu avec la livraison continue. Cependant, le déploiement continu signifie que toute modification apportée à la base de code est déployée automatiquement en production, tandis que la livraison continue prépare la fonctionnalité à être publiée en production, mais le moment du déploiement est dicté par l’équipe. Ensemble, ces pratiques rendent toute publication beaucoup moins risquée.

Intégration continue et feature flags

Il peut arriver qu’un développeur ait terminé ses modifications et les ait intégrées dans la ligne principale, tandis que le travail d’un autre développeur n’est pas encore terminé. Cela peut poser problème, car la fonctionnalité ne peut pas être publiée tant que tous les développeurs n’ont pas terminé leurs modifications, ce qui peut retarder le processus d’intégration.

Ce problème peut être résolu en utilisant des feature flags, qui permettent d’activer ou de désactiver certaines parties du code. Ainsi, une fonctionnalité incomplète reste désactivée jusqu’à ce qu’elle soit prête à être publiée. Une fois prête, elle peut être activée d’un simple clic. L’utilisation de feature flags dans un tel scénario permet donc de maintenir la branche principale en bon état.

Dernières réflexions et meilleures pratiques

L’intégration continue permet des déploiements fréquents. Elle permet de publier vos versions plus rapidement auprès de vos utilisateurs et d’obtenir davantage de retours sur ces fonctionnalités. Elle facilite également la collaboration entre les développeurs, augmentant ainsi leur productivité et la qualité de leurs publications.

Voici quelques bonnes pratiques pour vérifier si votre équipe applique réellement l’intégration continue, comme listé par Martin Fowler dans son article détaillé sur le sujet :

• Maintenez un référentiel source unique.
• Automatisez les builds.
• Rendez le build auto-testable.
• Commitez sur la base chaque jour.
• Chaque commit doit être construit.
• Réparez immédiatement les builds cassés.
• Gardez le build rapide.
• Testez dans un clone de l’environnement de production.
• Facilitez l’accès à l’exécutable le plus récent.
• Assurez-vous que tout le monde peut voir ce qui se passe.
• Automatisez les déploiements.