L'intégration continue est un processus de développement logiciel dans lequel les développeurs intègrent le nouveau code plus fréquemment, tout au long du cycle de développement, en l'ajoutant au code base au moins une fois par jour. Des tests automatisés sont effectués à chaque itération du build pour identifier les problèmes d'intégration plus tôt, lorsqu'ils sont plus faciles à résoudre et éviter ainsi les problèmes lors de la fusion finale de la version. Globalement, l'intégration continue permet de rationaliser le processus de génération, et donc de produire des logiciels de meilleure qualité et de mettre en place des calendriers de distribution plus prévisibles.
Par définition, DevOps décrit un processus de développement logiciel et un changement de culture organisationnelle qui accélère la distribution de logiciels de meilleure qualité en automatisant et en intégrant les efforts des équipes de développement et des opérations informatiques, deux groupes qui, traditionnellement, travaillaient séparément ou de manière isolée.
Dans la pratique, les meilleurs processus et cultures DevOps vont au-delà du développement et des opérations pour intégrer, dans le cycle de vie du développement logiciel, les contributions de toutes les parties prenantes de l'application, notamment l'ingénierie de la plateforme et de l'infrastructure, la sécurité, la conformité, la gouvernance, la gestion des risques, les métiers, les utilisateurs finaux et les clients.
Dans le cadre de DevOps , l'intégration continue se situe au début du processus de développement logiciel, où vous vérifiez le code au moins une fois par jour pour éviter que les copies locales ne s'éloignent trop de la branche principale de génération du code. Cela vous permet d'éviter les conflits de fusion désastreux qui pourraient "casser" la génération et dont la résolution pourrait prendre plusieurs heures, voire plusieurs jours, à l'équipe.
L'intégration continue est un prérequis pour les étapes de test, de déploiement et de publication de la distribution continue. L'ensemble de l'équipe de développement saura, quelques minutes après la remontée de code, si vous avez créé un code de mauvaise qualité, car le service d'intégration continue génère et teste automatiquement les modifications de code pour détecter toute erreur.
La distribution continue et le déploiement continu interviennent après l'intégration continue dans le cycle DevOps.
La distribution continue (CD) reprend là où l'intégration continue s'arrête, en automatisant la distribution des applications dans des environnements d'infrastructure sélectionnés. Elle vise à distribuer les modifications validées du code base (mises à jour, correctifs de bogue, nouvelles fonctions) aux utilisateurs aussi rapidement que possible avec une sécurité maximale. Elle automatise l'envoi des modifications du code à différents environnements, tels que les environnements de développement, de test et de production.
Dans le déploiement continu, les modifications du code d'une application sont publiées automatiquement dans l'environnement de production. Cette automatisation repose sur une série de tests prédéfinis. Lorsque les tests des nouvelles mises à jour aboutissent, le système envoie les mises à jour directement aux utilisateurs du logiciel.
L'intégration continue offre généralement les avantages suivants :
Agile est une pratique de développement logiciel qui améliore la façon dont les équipes de développement logiciel s'organisent, s'adaptent aux changements d'exigences et publient les logiciels. Étant donné que l'intégration continue (lien externe à IBM) et le développement agile partagent de nombreuses fonctionnalités (par exemple, l'automatisation des tests), il convient de les traiter en même temps. Agile organise le développement en petits groupes de travail ou sprints. Lorsqu'elles sont appliquées dans le cadre du DevOps, ces pratiques combinées permettent de garantir la qualité des logiciels et la flexibilité des projets.
L'intégration continue vous oblige à intégrer le travail fréquemment, souvent plusieurs fois par jour. Vous vérifiez l'intégration par une construction automatisée qui détecte les erreurs d'intégration le plus tôt possible. La génération doit inclure des tests d'exécution dans le cadre de la vérification. L'extension des tests rapides aux tests d'exécution dans un environnement de test automatisé conduit naturellement à la distribution continue.
La méthode Agile (lien externe à IBM) est également itérative et s'adapte au changement, de sorte qu'elle permet de faire évoluer les solutions au fil du temps. Dans le contexte de l'intégration continue, le développement Agile de logiciel consiste à distribuer des itérations logicielles basées sur la manière dont vous hiérarchisez la valeur des fonctionnalités au cours de l'intégration continue.
Les outils d'intégration continue open source les plus courants sont les suivants :
Réaliser l'intégration continue à l'aide d'outils open source offre de nombreux avantages, notamment :
Les outils d'intégration continue open source que vous pouvez envisager pour votre flux de travail de développement logiciel sont notamment Jenkins, Go, Buildbot et Travis CI. Vous trouverez des informations à leur sujet dans la section suivante.
Un serveur d'intégration continue est un outil logiciel qui centralise toutes les opérations d'intégration continue et fournit une plateforme fiable et stable pour la réalisation de vos projets. Vous pouvez configurer et ajuster des serveurs d'intégration continue pour générer divers projets pour différentes plateformes. Un serveur d'intégration continue modélise et visualise facilement des flux de travail complexes (permettant la distribution continue) et fournit une interface intuitive pour la construction de pipelines de distribution continue. Avec un serveur d'intégration continue, vous pouvez :
Le cas d'utilisation fictif suivant montre comment deux développeurs de logiciel peuvent utiliser l'intégration continue pour améliorer leur processus DevOps.
Les deux développeurs doivent communiquer entre eux pour savoir quelles fonctionnalités marchent et comment. Cette petite équipe a besoin de mises à jour régulières et doit être capable d'intégrer et de tester son code dans son ensemble. La planification de la remontée du code et des tests occupe une grande partie du temps de développement. Un système automatique d'intégration continue est nécessaire.
Négocier le moment où ces combinaisons et ces tests ont lieu est chronophage pour les développeurs. Ils doivent se mettent d'accord sur ce qui suit :
Les plateformes d'intégration continue ont des réponses par défaut à ces questions, et la plupart permettent la configuration et l'installation.
En général, les plateformes CI comme Jenkins commencent les tests d'intégration au moment de la remontée. Lorsque le nouveau code est remonté, le système CI exécute un ensemble de tests qui peuvent inclure des tests unitaires et des tests de régression, puis détermine si le code a été correctement intégré.
Si vous utilisez un langage compilé, le test par défaut consistera à savoir si le code se compile correctement. Si ce n'est pas le cas, cela signifie que le nouveau code n'a pas été intégré. Pour les langages comme Python ou JavaScript, vous devez créer votre propre test d'intégration.
Dans tous les cas, la plupart des systèmes CI enregistrent les tentatives d'intégration, le taux de réussite et d'autres mesures.
L'importance des tests
Les tests continus commencent lorsque vous produisez un build d'intégration continue et un package (également connu sous le nom d'entité installable ou entité packagée). Ils s'arrêtent lorsque ce package est mis en production. Chaque étape de bout en bout implique une suite de tests.
Au minimum, lorsque vous n'avez qu'une seule étape de test, 30 % de l'intégration continue implique des tests. En réalité, les activités d'intégration continue sont constituées de 50 à 70 % de tests. Auparavant, les tests devaient être effectués manuellement. Vous pouvez désormais utiliser des tests automatisés pour réussir votre intégration continue.
Dans le cadre de l'automatisation des tests pour l'intégration continue, le développement axé sur les tests génère itérativement le code et les tests, un cas d'utilisation à la fois, afin de garantir la couverture des tests, d'améliorer la qualité du code et d'établir la base de la distribution continue. Les tests automatisés indiquent si le nouveau code a échoué à un ou plusieurs des tests développés dans tous les domaines fonctionnels de l'application. Il est recommandé que les développeurs exécutent tous les tests ou un sous-ensemble de tests dans leurs environnements locaux afin que le code source puisse uniquement être validé dans le contrôle de version si les nouvelles modifications du code ont réussi les tests. L'expérience montre qu'un test de régression efficace permet d'éviter les mauvaises surprises par la suite.
Le pipeline d'intégration continue
Un pipeline d'intégration continue automatise les étapes du pipeline d'un projet, telles que les générations, les tests et les déploiements, de façon reproductible et avec une intervention humaine minime. Un pipeline d'intégration continue automatisé est essentiel pour optimiser le développement, les tests et le déploiement de vos applications en termes de vérifications, de points de contrôle et de rapidité.
Bonnes pratiques d'intégration continue
Le processus d'intégration continue est un élément essentiel du DevOps. Il permet d'unifier les équipes de développement et des opérations dans un référentiel partagé pour coder, tester, déployer et assurer le support des logiciels. Voici quelques bonnes pratiques de CI qui peuvent vous aider à réussir :
Le DevOps accélère la livraison de logiciels de qualité optimale en combinant et en automatisant le travail des équipes de développement logiciel et des opérations informatiques.
La distribution continue automatise la distribution des applications vers les environnements de test et de production.
Un guide pratique du pipeline d'intégration continue/de distribution continue (CI/CD).