Intégration vs. livraison vs. déploiement continus
Si vous êtes dans le domaine du développement logiciel depuis un certain temps, vous êtes probablement tombé sur le terme CI/CD.
L'intégration, la livraison et le déploiement continus sont des pratiques qui visent à accélérer le processus de publication des logiciels en raccourcissant les boucles de feedback et en automatisant les tâches répétitives. Ces pratiques jouent un rôle clé dans la réalisation du principe Agile visant à livrer fréquemment aux utilisateurs des logiciels fonctionnels et utiles.
Pour les équipes qui ont trouvé leur rythme et mis en place les outils et les processus de CI/CD pour soutenir un cycle de publication régulier, un pipeline CI/CD efficace est source de fierté : un signe que les développeurs utilisent leurs outils pour améliorer à la fois leur propre environnement et le produit final qu'ils créent.
Cependant, pour quelqu'un qui débute dans cette pratique, le fait de transformer son processus de build, de test et de déploiement en un système automatisé peut sembler intimidant et irréalisable. Il n'est pas nécessaire que ce soit le cas. La beauté de la construction d'un pipeline CI/CD est qu'il se prête parfaitement à être décomposé en étapes distinctes, chacune s'appuyant sur la précédente. Examinons chacune d'entre elles tour à tour.
Il est temps de définir plus en détail les différences entre l'intégration continue (CI) et le développement continu (CD).
Qu'est-ce que l'intégration continue ?
L'intégration continue est la pratique consistant à exécuter les étapes qui étaient traditionnellement réalisées lors de « l'intégration », petit à petit et fréquemment, tout au long du processus de développement, plutôt que d'attendre que le code soit complet avant de le compiler et de le tester.
En supposant que plusieurs personnes travaillent sur un produit logiciel, ce qui est la norme pour la plupart des logiciels commerciaux et open-source, vous devez, à un moment donné, combiner les éléments sur lesquels chaque développeur a travaillé et vérifier que le résultat final fonctionne comme prévu. Avec l'intégration continue, cela se produit au moins une fois par jour, sinon plus.
Le raisonnement est simple. Si vous attendez que tout le code soit écrit pour procéder à l'intégration, il y a de fortes chances que vous deviez passer un temps considérable à décortiquer et à réécrire des sections de votre code pour que la solution réussisse à compiler, sans parler de la faire fonctionner comme prévu. Le codage est complexe. Même avec une planification détaillée, il est incroyablement difficile de prévoir exactement comment la logique va interagir et éviter tout problème. Plus il y a de code, plus la complexité est grande et plus il y a de choses à décortiquer lorsque quelque chose ne fonctionne pas.
Avec l'intégration continue, vos développeurs partagent leurs modifications en les engageant régulièrement dans le contrôle de code source (au moins une fois par jour) et vérifient que la solution se compile et passe les tests. Cela signifie que si quelque chose casse, il y a beaucoup moins de modifications à vérifier pour trouver la source du problème. Le retour d'information rapide facilite également la résolution des problèmes, car vous ne perdez pas le contexte de ce que vous faites.
Un bon processus de CI nécessite quelques ingrédients essentiels :
Utiliser le contrôle de code source
Un système de contrôle de code source (ou de versions) est absolument essentiel. Si vous n'en avez pas, ou si une partie seulement de votre code est dans le contrôle de code source, la première étape est de tout y mettre et de faire en sorte que tout le monde l'utilise.
Valider tôt, valider souvent
Une fois que vous utilisez le contrôle de code source, faites en sorte que tout le monde prenne l'habitude de valider tôt et souvent. La taille de la tâche peut avoir un impact ici. En décomposant chaque tâche en plus petits morceaux, il est plus facile de compléter et de tester localement une série de modifications pour qu'elles soient prêtes à être validées.
Compiler votre solution à chaque commit
Partager régulièrement vos modifications de code avec tous les membres du projet n'est qu'un début. L'étape suivante consiste à vérifier que la solution peut toujours être compilée avec les dernières modifications. Bien que cela puisse être fait manuellement, il est beaucoup plus facile et plus efficace de déclencher la compilation automatiquement, et c'est là qu'intervient un serveur de CI.
Automatiser les tests
Une compilation réussie est un bon signe, mais pour plus de confiance, il est utile de faire quelques tests. Là encore, il est beaucoup plus facile et efficace d'effectuer des tests automatiquement que manuellement. Bien qu'écrire des tests automatisés puisse sembler laborieux, ils sont vite rentabilisés lorsque vous les exécutez sur chaque build pour obtenir des retours rapides.
Écouter les retours
L'automatisation des builds et des tests ne vaut la peine que si vous voulez faire quelque chose avec les informations que vous obtenez en retour. Les outils de CI offrent toute une gamme de mécanismes de retour d'information, allant des tableaux de bord et des radiateurs à l'intégration avec les plateformes de messagerie instantanée.
Développer une culture DevOps
Pour vraiment récolter les bénéfices de l'intégration continue, vous devez créer une culture d'équipe où chacun prend la responsabilité de réparer les builds cassés ou les tests ratés. Il est contre-productif de rejeter la faute sur la personne qui a effectué le dernier commit, car cela dissuade souvent votre équipe de procéder à un commit rapide et fréquent des modifications alors que cela serait dans l'intérêt de tous.
En réunissant tous ces ingrédients, vous obtenez un retour d'information rapide et régulier sur votre code. En veillant à ce que chaque modification apportée à la base de code, qu'il s'agisse d'une correction de bug, d'une refactorisation ou d'une partie d'une nouvelle fonctionnalité, entraîne au moins un build propre qui passe les tests, les équipes peuvent éviter de réaliser de nouveaux travaux sur de mauvaises fondations et les inévitables retouches qui s'ensuivent. L'implémentation d'une intégration continue est en soi un grand pas vers l'accélération du processus de livraison de logiciels fonctionnels à vos utilisateurs.
Comprendre la livraison continue
La livraison continue s'appuie sur les bases de l'automatisation des builds et des tests établies avec l'intégration continue.
Avec la livraison continue, vous transformez les étapes manuelles utilisées pour faire passer un build de votre logiciel en production en un processus automatisé.
Là où, par le passé, il pouvait y avoir un transfert de vos développeurs vers les testeurs, puis des testeurs vers les responsables de publication, avec la livraison continue, votre équipe (qui peut comprendre des personnes de différentes disciplines) est responsable de l'ensemble du processus de création, de test et de publication de son produit. Cela présente plusieurs avantages :
- En évitant les silos traditionnels, votre équipe de développement a une meilleure compréhension des besoins commerciaux et opérationnels pour livrer leur produit à vos utilisateurs.
- En retour, cela crée une opportunité de ramener les pratiques de développement à ce qui était typiquement un processus manuel, et souvent assez long.
- L'automatisation des étapes de la livraison d'un produit non seulement accélère le processus mais réduit également le risque d'erreurs et le rend plus stable et plus fiable.
Les étapes exactes de la livraison de logiciels à vos utilisateurs, et donc les étapes requises dans le pipeline de livraison, varient en fonction des besoins de l'entreprise et des utilisateurs, mais il est courant de les déployer dans au moins un environnement de pré-production avant qu'ils ne soient publiés officiellement.
Il peut s'agir d'environnements de test pour des niveaux de test supplémentaires, tels que des tests de sécurité, de charge et de performance ; d'environnements sandbox pour les équipes de support et de vente afin de se familiariser avec les nouvelles fonctionnalités ; et d'environnements de test d'acceptation pour les professionnels de l'assurance qualité et des produits afin de vérifier que les modifications fonctionnent comme prévu.
Avec la livraison continue, chaque build réussi est automatiquement déployé dans chacun des environnements de pré-production, la fiabilité de la qualité augmentant à chaque étape.
Il s'agit d'un objectif intéressant qui nécessite un certain investissement pour être mis en pratique :
Build unique
Ce n'est qu'en promouvant le même artefact de build à travers chaque étape du pipeline que vous pouvez avoir la certitude qu'il a passé toutes les étapes de test antérieures.
Stocker la configuration dans le contrôle de code source
Le fait de conserver tous ces fichiers de configuration dans le contrôle de code source permet de s'assurer que les déploiements sont consistants et reproductibles.
Automatiser chaque déploiement
Le déploiement dans chaque environnement doit être scripté afin qu'il puisse être exécuté automatiquement, et donc exactement de la même manière, à chaque fois. La publication en production doit être scriptée pour la même raison, mais avec la livraison continue, cette dernière étape n'est pas automatique.
Nettoyer vos environnements
Pour une approche totalement consistante, les environnements eux-mêmes doivent être remis dans les mêmes conditions à chaque nouveau déploiement. Grâce aux conteneurs, cela est désormais beaucoup plus facile à implémenter, que ce soit sur une infrastructure locale ou dans le Cloud.
Séparer les préoccupations environnementales
Afin d'automatiser le déploiement d'un même artefact dans chaque environnement, il est nécessaire de séparer clairement l'application à proprement parler et les variables ou paramètres spécifiques à l'environnement.
Maintenir le pipeline
Comme pour l'intégration continue, il ne vaut la peine d'investir dans un pipeline de livraison continue automatisé que si vous le maintenez. Le CI/CD est autant une question de culture d'équipe que de processus et d'outils. Pour être efficace, votre équipe doit prendre la responsabilité de maintenir le pipeline et de corriger tout problème qui survient, que ce soit en raison d'un bug dans le code lui-même ou d'un problème lié aux déploiements ou aux tests automatisés.
Avec la livraison continue, votre équipe assume la responsabilité de la livraison des logiciels et bénéficie d'un retour d'information rapide tout au long du processus. Comme pour l'intégration continue, la pratique peut être développée et améliorée au fil du temps.
Explication du déploiement continu
Le déploiement continu amène les pratiques d'intégration et de livraison continue à leur conclusion logique :
si un build passe avec succès toutes les étapes précédentes dans le pipeline, il est automatiquement publié en production. Cela signifie que dès qu'une modification apportée à votre logiciel a passé tous les tests, elle est livrée à vos utilisateurs. Le déploiement continu raccourcit la boucle de feedback entre la modification du code et son utilisation en production, ce qui permet à votre équipe d'avoir un retour d'information rapide sur les performances de ses modifications dans le monde réel sans avoir à faire de compromis sur la qualité.
Bien que l'automatisation du déploiement de logiciels en production ne convienne pas à tous les produits et organisations, il est utile de considérer les étapes nécessaires pour y parvenir, car chaque élément individuel est important en soi :
Avoir confiance en vos tests
Le déploiement en production automatique nécessite un niveau de confiance élevé dans votre pipeline, en particulier dans vos tests automatisés. Une excellente culture de test, où votre équipe investit dans la couverture et les performances des tests et donne la priorité à la correction des builds et du pipeline plutôt qu'aux nouvelles fonctionnalités, est essentielle.
Surveiller la production
Même si toutes les mesures ci-dessus sont en place, le déploiement continu peut sembler être une pratique risquée : que se passe-t-il si un bug n'est pas détecté lors des tests et qu'il apparaît seulement en production ? Du temps, de l'argent et votre réputation sont potentiellement en jeu. Bien que le même problème puisse se poser avec un déploiement manuel, rien de tel qu'un bug critique publié automatiquement par « le système » pour perdre la confiance de vos parties prenantes. C'est là que la recherche proactive de signes de problèmes plutôt que la nécessité d'attendre la réception de rapports de bugs fait toute la différence. Le contrôle des statistiques pour détecter tout changement par rapport à la norme, en particulier juste après une publication, peut vous signaler des problèmes avant qu'ils ne causent un problème notable à vos utilisateurs.
Choisir ce qu'il faut publier
Une objection courante de la part des nouveaux venus dans le domaine du déploiement continu est que si vos développeurs valident tôt et souvent et laissent les choses se faire sans une supervision manuelle, alors vos utilisateurs trouveront des fonctionnalités inachevées ou incomplètes qui ne sont pas prêtes à être utilisées. Plutôt que de recourir à des branches et de passer à côté des avantages d'une intégration continue, la solution consiste à utiliser des feature flags. Vos développeurs peuvent alors contrôler ce qui est visible et ce qui est caché à l'utilisateur lorsqu'ils écrivent le code.
Rationaliser votre pipeline
Si un problème survient en production, vous voulez pouvoir réagir rapidement. Dans certains cas, il peut être possible de revenir à la version précédente. Cependant, les choses ne sont souvent pas aussi simples : les migrations de bases de données et les corrections de problèmes connus peuvent empêcher toute rétroaction et obliger à mettre en œuvre un correctif. Sauter des étapes de votre pipeline est une fausse économie, car vous risquez d'introduire d'autres problèmes qui auraient pu être détectés si vous aviez effectué vos tests normalement. Il est préférable d'investir dans la rationalisation de votre pipeline, de la vitesse de compilation aux performances des tests. Non seulement cela signifie que vous pouvez rapidement déployer les modifications lorsque vous en avez besoin, mais cela raccourcit également les boucles de feedback tout au long du processus.
Contrôler le déploiement
Bien que le déploiement continu signifie la publication automatique si toutes les étapes précédentes sont franchies, cela ne signifie pas que l'on abandonne tout contrôle. Il existe diverses pratiques de déploiement qui sont utilisées pour minimiser les risques et contrôler le déploiement. Les publications Canary vous permettent de tâter le terrain avec une petite partie de vos utilisateurs dans un premier temps, tandis que des déploiements bleu-vert peuvent être utilisés pour gérer la transition vers une nouvelle version.
L'intégration, la livraison et le déploiement continus ont pour but de fournir fréquemment à vos utilisateurs des logiciels utiles et fonctionnels. L'adoption d'une approche visant à publier fréquemment de petites modifations rend le processus plus facile à gérer et signifie que les équipes répètent régulièrement les étapes et se perfectionnent avec ces dernières.
L'automatisation permet non seulement d'accélérer le processus, mais aussi de le rendre plus fiable. Chaque étape du pipeline s'appuie sur la précédente, et vous pouvez choisir le seuil qui vous convient à un moment donné et y revenir plus tard.
Différences clés entre CI et CD
L'intégration continue, la livraison et le déploiement constituent des phases séquentielles du processus de livraison des logiciels. Ils permettent aux équipes de publier les logiciels plus rapidement, de raccourcir la boucle de rétroaction et d'automatiser les tâches répétitives. Identifier les différences clés entre l'intégration continue, la livraison et le déploiement est aussi important que de comprendre comment ces trois étapes interagissent pour livrer des logiciels aux utilisateurs de façon fiable et stable.
L'intégration continue consiste à fusionner tout nouveau changement de code dans la branche principale. La livraison continue automatise les tâches manuelles requises pour créer et tester les logiciels (par exemple, en automatisant les tests). Le déploiement continu est le prolongement logique de l'automatisation des builds et des étapes de test, et à ce stade, les logiciels sont déployés automatiquement une fois qu'ils satisfont tous les points de contrôle.
Plus simplement, il ne s'agit pas d'opposer l'intégration continue au développement continu, mais de comprendre comment leur interaction permet d'obtenir un pipeline stable et fiable.