Comprendre l'intégration continue

L'intégration continue (CI) est une pratique DevOps permettant aux équipes de développement de travailler plus efficacement et de livrer des logiciels de façon plus fiable. Avec la CI, à chaque fois que vous fusionnez vos modifications, un serveur de CI crée un build et teste automatiquement votre code, afin d'obtenir des retours rapides sur votre travail. Ce cycle fiable et rapide de rétroaction permet de publier des modifications plus fréquemment et de réduire le nombre de bugs introduits en production.

Développement sans intégration continue

Pour comprendre pourquoi l'intégration continue est nécessaire, il est utile de considérer à quoi ressemble le développement logiciel sans ce processus. Supposons que vous travailliez avec un système de contrôle de version tel que Git. Vous et vos collègues disposez chacun de votre propre copie du référentiel, que vous utilisez pour développer localement avant de faire un push de vos modifications sur un référentiel partagé.

Si vous développez une nouvelle fonctionnalité, il peut être nécessaire de travailler dessus pendant plusieurs jours avant de partager vos modifications. Pendant ce temps, vos collègues développent d'autres fonctionnalités sur leur copie locale du référentiel. Une fois que vous avez terminé, chacun fait un push de ses modifications sur le référentiel partagé et les fusionne avec la branche voulue afin de tester que chaque fonctionnalité fonctionne comme prévu lorsqu'elle est combinée avec tout le reste.

Malheureusement, parce que vous combinez un gros volume de modifications provenant de plusieurs développeurs, le risque d'échec du processus de build est élevé. Vous et vos collègues passez du temps à identifier les modifications à l'origine du problème et êtes confrontés à un dilemme : annuler les derniers commits et publier une version intégrant d'autres modifications plus urgentes, ou retravailler le code pour corriger les problèmes.

Une fois votre code au stade de build, vous risquez de vous apercevoir que la combinaison des modifications a introduit de nouveaux bugs. Encore une fois, vous examinez les modifications de chaque contributeur pour remonter à la source des problèmes, les corriger, puis recommencer le processus de build.

Utilité de l'intégration continue

L'intégration continue accélère ce processus en automatisant les phases de build et de test, et en les exécutant à chaque fois que vous fusionnez vos modifications dans la branche voulue. Une fois ces étapes automatisées, il devient possible de les exécuter plus souvent et, au lieu de créer un build et de tester votre base de code à des semaines d'intervalle, vous pouvez le faire plusieurs fois par jour.

En travaillant en plus petits incréments, il devient possible d'identifier et de corriger les problèmes introduits par vos modifications du code plus rapidement. Au lieu d'examiner des milliers de lignes de modifications pour trouver la source du problème, vous pouvez vous concentrer sur un ensemble de modifications beaucoup plus restreint. De plus, ces modifications sont encore fraîches dans votre esprit, ce qui vous évite d'avoir à tout remettre en contexte.

En confirmant que votre logiciel crée bien un build et se comporte comme prévu après chaque modification, la CI permet de disposer d'un code constamment prêt pour le déploiement. Ainsi, la mise en production des modifications devient moins ardue et vous pouvez envisager de fournir vos nouvelles fonctionnalités et les correctifs plus souvent.

L'intégration continue a été conçue en réponse aux problématiques des grands projets de développement faisant intervenir de nombreux contributeurs, mais il n'est jamais trop tôt pour l'intégrer dans votre processus de développement. Même si vous travaillez seul, la répartition de votre travail en petites unités validées régulièrement par des tests automatisés peut vous aider à gagner en efficacité et améliorer la qualité du code.

Un workflow de CI efficace fait intervenir une combinaison d'outils, de processus et de pratiques de travail en équipe. Nous allons les examiner tour à tour.

Utiliser un système de contrôle de version

L'intégration continue nécessite que l'intégralité de votre base de code soit enregistrée dans un système de contrôle de la version/source. Cela doit inclure tous les fichiers de code source, les bibliothèques, les fichiers de configuration et les scripts. L'introduction du contrôle de version simplifie considérablement la tâche des développeurs devant travailler en parallèle et partager leurs modifications. Les serveurs de CI s'intègrent avec les systèmes de contrôle de version pour créer un build et tester les modifications apportées à votre code.

Effectuer régulièrement des commits des modifications

Pour que tout le monde bénéficie d'un socle commun, vous devez travailler à partir du même référentiel et partager fréquemment vos modifications. En règle générale, tous les membres de l'équipe doivent fusionner leurs commits dans la branche de CI de votre référentiel au moins une fois par jour, voire plus souvent si possible. Dans le même temps, assurez-vous que votre copie locale reste à jour par rapport au référentiel partagé, afin de réduire les risques de conflits de fusion à chaque push.

Builds et tests automatisés

Une fois les modifications de votre code fusionnées, l'étape suivante consiste à créer un build de la solution et de le soumettre à une batterie de vérifications, telles que le linting, les tests unitaires et l'analyse statique. Les processus manuels de création de build et/ou de test sont chronophages et sujets à erreurs, ce qui rend difficile l'intégration quotidienne des modifications. Par conséquent, l'automatisation s'impose. Des outils de build et des frameworks de test automatisés sont disponibles pour tous les langages de programmation majeurs, et vous pouvez utiliser un serveur de CI pour automatiser le processus et coordonner les différentes étapes.

Traiter rapidement les échecs

Pour profiter des avantages de l'intégration continue, toutes les personnes contribuant au projet réagir rapidement en cas d'échec du processus automatisé de build ou de test. Ainsi, tout le monde travaille sur des bases solides et cela évite de greffer de nouvelles fonctionnalités sur du code erroné. Bien que cela puisse sembler que vous demandez aux membres de l'équipe d'interrompre leur travail pour corriger un build ou un test ayant échoué, un processus de CI automatisé peut produire des résultats en quelques minutes, ce qui vous permet de résoudre les problèmes pendant que les modifications du code sont encore fraîches dans votre esprit.

Maintenir le processus

Une fois vos builds et tests automatisés, vous devez maintenir votre flux de CI. Cela inclut l'ajout de tests unitaires pendant que vous écrivez du code et le maintien de la vitesse de vos boucles de rétroaction.

L'ajout d'un serveur de CI pour contrôler votre référentiel, déclencher les builds, exécuter des tests automatisés et collecter les résultats contribue à rassembler tous ces éléments, ce qui vous fait gagner du temps lors de l'écriture d'une logique d'automatisation personnalisée. Un bon serveur de CI peut également fournir des informations supplémentaires, telles que des métriques de couverture du code et l'historique des builds.

Une vision claire des avantages offerts par l'intégration continue permet d'inciter les membres de l'équipe à essayer de nouvelles méthodes de travail et de convaincre vos intervenants d'adopter les nouveaux processus.

Pour les individus et l'équipe de développement en général, la CI présente les avantages suivants :

• Fusions plus fluides : dès que vous commencez à travailler sur des unités plus réduites, le nombre de conflits de fusion diminue. La mise à jour régulière de votre référentiel local pour intégrer les modifications poussées par des tiers est essentielle pour cela.
• Workflow plus efficace : les retours rapides d'un processus automatisé de build et de test permettent de mettre en évidence les problèmes présents dans le code quelques minutes seulement après avoir fait un push des modifications. Par contraste, si vous dépendez d'un processus manuel de build ou de test, vous risquez de ne découvrir les bugs introduits par vos modifications que quelques jours, voire quelques semaines plus tard.
• Base de code plus facile à maintenir : la mise en place d'une couverture de test automatisée pour s'assurer que votre processus de CI fonctionne correctement rend votre base de code plus simple à comprendre et à maintenir.
• Communication et collaboration améliorées : en travaillant en plus petits incréments et en partageant les modifications plus régulièrement, il devient plus facile de savoir ce sur quoi les autres travaillent. Cela crée des opportunités de collaboration plus poussée lors de la conception de fonctionnalités, permet d'indiquer le degré de progression aux responsables produit et aux experts en ergonomie, et de changer de cap si nécessaire.

L'intégration continue présente également des avantages pour le reste de l'entreprise, notamment :

• Moins de bugs : l'intégration continue ne permet pas de supprimer tous les bugs, mais elle facilite considérablement leur identification et correction. Cela permet de limiter radicalement les risques d'introduction de bugs dans la phase de production, là où ils risquent d'avoir un impact sur vos utilisateurs.
• Publications plus rapides et fréquentes : l'automatisation des processus de build et de test libère du temps et permet de s'assurer que les étapes sont exécutées de façon homogène, ce qui réduit les efforts manuels de préparation du logiciel en vue de sa publication. Au fur et à mesure que les équipes se familiarisent avec leur processus de CI, elles peuvent publier les modifications plus fréquemment.

Pour avoir plus d'informations sur les avantages de l'intégration continue, la livraison et le déploiement, lisez notre guide sur les 12 avantages du CI/CD.

Défis de l'intégration continue

L'intégration continue présente des avantages aussi bien pour les développeurs que le reste de l'entreprise, mais n'est pas toujours accueillie à bras ouverts.

Pour de nombreux services de développement, le DevOps représente un grand changement dans leur façon de travailler et remet en question les processus existants. Une bonne communication est nécessaire pour coordonner le travail des équipes et instaurer une culture axée sur la collaboration.

Si vous appliquez déjà des méthodologies agiles, le changement est généralement plus facile, car l'importance accordée aux retours d'informations et la notion d'équipes auto-organisées sont probablement déjà en place.

Si ce n'est pas le cas, reconnaître que l'intégration continue constitue un changement important, établir un dialogue, commencer doucement et démontrer les avantages au fur et à mesure sont autant de moyens de convaincre vos collègues des avantages de l'intégration continue.

L'intégration continue se heurte également à des défis plus terre à terre. Les temps de build peuvent être lents si vous travaillez sur une grande application monolithique, et la parallélisation des exécutions de test peut devenir difficile s'il n'y a pas assez d'environnements de test.

Avoir une bonne visibilité de votre workflow d'intégration continue et utiliser des indicateurs pour identifier les goulets d'étranglement, permet de mieux quantifier les coûts et les avantages liés à l'investissement dans des changements d'architecture, des infrastructures supplémentaires et la couverture des tests automatisés.

La mise en place d'un workflow de CI peut sembler intimidante. De nombreux paramètres doivent être pris en compte et beaucoup de choses peuvent être automatisées. Heureusement, ce processus peut facilement être divisé en éléments plus petits, car chaque étape présente un certain nombre d'avantages.

Les éléments suivants constituent un bon point de départ :

1. Travailler en plus petits incréments : tant que votre code est dans un système de contrôle de version, vous pouvez commencer à travailler sur des lots plus petits et partager les modifications plus fréquemment, ce qui réduit les conflits de fusion. Il peut être utile de commencer à décomposer les tâches de développement pendant l'ajustement du backlog pour faciliter cela.
2. Convenir d'une stratégie de branching : cela détermine la ou les branches devant suivre le processus de CI et comment les modifications sont publiées. Les choix communs incluent le développement axé sur le tronc et GitFlow (en particulier pour les logiciels soumis à des versions).
3. Ajouter de tests unitaires pendant le processus de codage : que vous disposiez déjà de tests unitaires ou commenciez à partir de zéro, l'intégration des tests unitaires dans la « définition d'un travail terminé » permet de s'assurer que votre couverture de code s'améliore constamment. N'avoir que quelques tests automatisés est toujours préférable à n'en avoir aucun, et vous pouvez vous essayer à la CI avec uniquement une poignée de tests automatisés.
4. Automatiser progressivement : au lieu d'essayer de créer un script couvrant toutes les phases de votre flux de CI en une seule fois, focalisez-vous sur ce qui prend le plus de temps ou génère le plus de retours. Une fois votre processus prêt, vous pouvez utiliser un serveur de CI pour commencer à enchaîner les étapes au sein d'un processus de CI.

Vous trouverez plus d'informations sur les processus de CI et CD dans notre guide sur les bonnes pratiques de CI/CD.

L'adoption de l'intégration continue permet d'accélérer le processus de développement tout en améliorant la qualité du code. L'automatisation de ces étapes vous permet de travailler plus efficacement et de vous focaliser sur la valeur ajoutée pour vos utilisateurs. Toutefois, l'intégration continue n'est que le début du pipeline de CI/CD. L'étape suivante, la livraison continue, applique les principes DevOps au reste du processus de publication.

TeamCity est une plateforme flexible de CI/CD que vous pouvez personnaliser en fonction des besoins. Elle prend en charge tous les principaux systèmes de contrôle de version, tels que Git, Perforce, Mercurial et Subversion, et les outils de build et de test pour les langages de programmation majeurs. Les nombreux types de déclencheurs de CI permettent de lancer le processus de build et de test après chaque commit sur une branche donnée, d'exécuter un sous-ensemble de vérifications sur des branches de fonctionnalités, de planifier des créations de build la nuit et de donner aux membres de l'équipe la possibilité d'exécuter des vérifications de CI localement.

Afin d'obtenir des retours aussi rapidement que possible, TeamCity permet de paralléliser les tests et autres tâches de build. Les intégrations avec Slack et les IDE permettent d'obtenir des retours où que vous travailliez, tandis que les rapports de test détaillés accélèrent la recherche de la cause de l'échec. TeamCity inclut également toute une gamme de métriques permettant d'optimiser votre processus de CI et d'évaluer la couverture des tests unitaires.

Si vous décidez d'étendre votre processus de CI pour inclure la livraison continue ou le déploiement continu, TeamCity peut fournir tout ce dont vous avez besoin pour gérer les environnements et automatiser les déploiements.