Continuous integration (CI, intégration continue)

Pratiques courantes de l'intégration continue

D'après Paul Duvall, co-auteur de « Continuous Integration: Improving Software Quality and Reducing Risk », la CI se caractérise par les meilleures pratiques suivantes :

• Validation fréquente du code
• Catégorisation des tests par les développeurs
• Machine dédiée aux builds d'intégration
• Mécanisme de rétroaction en continu, et
• Builds de test

La CI peut intervenir à n'importe quelle fréquence, selon l'organisation qui la met en oeuvre et le projet dont il est question. En règle générale, les entreprises adeptes de la CI publient plus rapidement qu'avec les processus de développement logiciel antérieurs.

Chaque modification importante déclenche la création d'une build. Une équipe de développement peut décider de recourir à la CI pour une multitude de raisons, l'une d'entre elles étant de suivre constamment l'état du logiciel. En détectant les anomalies très tôt dans le cycle de développement, la CI permet de minimiser leurs effets et leur complexité et de les résoudre bien plus vite que si on les découvrait à un stade ultérieur.

Une équipe de développement peut recourir à l'automatisation lors de la configuration de la CI de manière à englober l'intégration et le test du code. Il est ainsi possible de détecter quasi-immédiatement la présence d'un problème dans le code et d'y apporter une solution plus rapidement que si ces tâches étaient assurées manuellement.

Les outils d'automatisation aident les équipes à mener les tests courants dans le cadre de l'intégration continue (test d'API et tests fonctionnels, notamment). Un test unitaire permet d'examiner les plus petits composants de l'application. Un test d'API évalue si une API peut ou non fonctionner fiablement avec la charge attendue de requêtes et de réponses. Un test fonctionnel porte généralement sur de plus gros blocs de code source et vise à simuler un workflow ou une fonction utilisateur.

En cas d'automatisation intégrale de la CI, ce sont des scripts et des moteurs d'intégration qui gèrent les allées et venues du nouveau code entre les tests et les builds.

Cette approche automatisée fait souvent partie d'un pipeline CI/CD et d'une méthodologie DevOps. La livraison continue s'inscrit dans le prolongement naturel de l'intégration continue, elle n'en est pas une alternative. L'intégration continue s'intéresse aux phases de test des builds et du code du cycle de développement, alors que la livraison continue suppose des tests de déploiement et une automatisation de la configuration. Dans ce cas, une équipe de développement crée un logiciel et le fait passer en production dans un délai très court. Le déploiement continu est une étape encore plus avancée, où le code passe automatiquement en production et devient immédiatement accessible aux utilisateurs.
[image : Enchaînement de l'intégration et de la livraison continues.

Avantages de l'intégration continue

Lorsque l'intégration continue s'inscrit dans le processus de développement, une équipe de développement peut apporter de sérieux avantages à une organisation.

La CI permet une intégration de code plus rapide et moins déstabilisante, puisque le code est intégré au fur et à mesure, à un rythme plus soutenu qu'avec d'autres approches de développement, comme le modèle en cascade. De même, les retours en arrière sont moins dérangeants, puisque seules les modifications isolées sont annulées d'emblée.

Il est plus facile et plus rapide de détecter les bogues, car si un problème survient, il y a de fortes chances qu'il se trouve dans le dernier lot de code fusionné. Ces deux avantages résultent de la visibilité accrue qu'ont les développeurs sur le code, au fur et à mesure qu'ils enrichissent le référentiel de code.

L'intégration continue permet aussi de suivre en permanence les modifications, ce qui au fil du temps améliore un produit.

Outils d'intégration continue

Une équipe de développement utilise des outils d'intégration continue pour automatiser les phases de construction d'une application et documenter soigneusement les opérations. Voici quelques exemples d'outils d'automatisation des pipelines de CI que l'on trouve couramment dans les services informatiques des entreprises. Il existe cependant tellement d'outils pour couvrir les étapes du pipeline de CI (contrôle des versions, tests, builds, stockage des historiques), qu'il est impossible de les décrire ici en détail.

Jenkins est un serveur d'automatisation d'intégration continue open source. Il peut distribuer des tests et des builds sur plusieurs machines. Des modules complémentaires étendent les fonctionnalités de Jenkins, notamment pour automatiser les tests unitaires et établir les comptes rendus. Un développeur peut créer une build d'un projet par le biais d'URL spécifiques, de validations dans un système de contrôle de version ou d'un système préprogrammé et séquentiel. Une fois un système testé, Jenkins offre également la possibilité de déployer le code dans le cadre de la livraison continue.

Le référentiel et la plateforme GitLab open source prennent en charge l'intégration et la livraison continues. GitLab peut lancer des tests unitaires et d'intégration sur plusieurs machines et fractionner les builds de façon à les exécuter sur plusieurs machines pour accélérer les cycles d'exécution du projet. Le logiciel prend également en charge les déploiements manuels pour la livraison continue vers les environnements de test et de production. GitLab permet encore d'assurer l'intégration avec des outils tels qu'Atlassian Jira, GitHub et Jenkins.

JetBrains TeamCity est un serveur d'intégration et de gestion destiné à l'intégration et à la livraison continues. TeamCity permet aux développeurs de tester le code avant de transférer les modifications dans une base de code. En cas d'échec, TeamCity envoie une notification. TeamCity dispose de grilles de builds, qui permettent aux développeurs d'exécuter plusieurs tests et builds pour des plateformes et des environnements différents. TeamCity prend en charge Docker, Jira ainsi que d'autres programmes.