Qu'est-ce que CI / CD? Intégration continue et livraison continue expliquées

L'intégration continue (CI) et la livraison continue (CD) incarnent une culture, un ensemble de principes de fonctionnement et un ensemble de pratiques qui permettent aux équipes de développement d'applications de fournir des modifications de code plus fréquemment et de manière plus fiable. L'implémentation est également connue sous le nom de pipeline CI / CD

CI / CD est l'une des meilleures pratiques à mettre en œuvre par les équipes devops. Il s'agit également d'une meilleure pratique de méthodologie agile, car elle permet aux équipes de développement de logiciels de se concentrer sur la satisfaction des exigences métier, la qualité du code et la sécurité, car les étapes de déploiement sont automatisées.

CI / CD défini

L'intégration continue  est une philosophie de codage et un ensemble de pratiques qui poussent les équipes de développement à implémenter de petits changements et à archiver fréquemment le code dans les référentiels de contrôle de version. Étant donné que la plupart des applications modernes nécessitent le développement de code dans différentes plates-formes et outils, l'équipe a besoin d'un mécanisme pour intégrer et valider ses modifications.

L'objectif technique de CI est d'établir une méthode cohérente et automatisée pour créer, empaqueter et tester des applications. Avec la cohérence du processus d'intégration en place, les équipes sont plus susceptibles de commettre des modifications de code plus fréquemment, ce qui conduit à une meilleure collaboration et à une meilleure qualité des logiciels.

La livraison continue  reprend là où l'intégration continue se termine. CD automatise la livraison des applications à des environnements d'infrastructure sélectionnés. La plupart des équipes travaillent avec plusieurs environnements autres que la production, tels que les environnements de développement et de test, et le CD garantit qu'il existe un moyen automatisé de leur envoyer les modifications de code.

Les outils CI / CD aident à stocker les paramètres spécifiques à l'environnement qui doivent être fournis avec chaque livraison. L'automatisation CI / CD effectue ensuite tous les appels de service nécessaires aux serveurs Web, bases de données et autres services qui peuvent nécessiter un redémarrage ou suivre d'autres procédures lors du déploiement des applications.

L'intégration continue et la livraison continue nécessitent  des tests continus  car l'objectif est de fournir des applications et du code de qualité aux utilisateurs. Les tests continus sont souvent mis en œuvre sous la forme d'un ensemble de tests de régression, de performances et d'autres tests automatisés exécutés dans le pipeline CI / CD.

Un cabinet de développement CI / CD mature a la possibilité de mettre en œuvre un déploiement continu où les modifications d'application s'exécutent via le pipeline CI / CD et les versions de passage sont déployées directement dans les environnements de production. Les équipes pratiquant la livraison continue choisissent de se déployer en production selon un calendrier quotidien ou même horaire, bien que la livraison continue ne soit pas toujours optimale pour chaque application métier.  

Vidéo connexe: Comment fournir du code plus rapidement avec CI / CD

Comment l'intégration continue améliore la collaboration et la qualité

L'intégration continue est une philosophie de développement soutenue par la mécanique des processus et une certaine automatisation. Lorsqu'ils pratiquent le CI, les développeurs engagent fréquemment leur code dans le référentiel de contrôle de version et la plupart des équipes ont une norme minimale de validation de code au moins quotidiennement. La raison derrière cela est qu'il est plus facile d'identifier les défauts et autres problèmes de qualité logicielle sur des différentiels de code plus petits plutôt que sur des différentiels plus importants développés sur une longue période de temps. De plus, lorsque les développeurs travaillent sur des cycles de validation plus courts, il est moins probable que plusieurs développeurs modifient le même code et nécessitent une fusion lors de la validation.

Les équipes mettant en œuvre l'intégration continue commencent souvent par la configuration du contrôle de version et les définitions de pratique. Même si l'archivage du code est fréquemment effectué, les fonctionnalités et les correctifs sont mis en œuvre à la fois sur des délais courts et plus longs. Les équipes de développement qui pratiquent l'intégration continue utilisent différentes techniques pour contrôler les fonctionnalités et le code prêts pour la production.

De nombreuses équipes utilisent des indicateurs de fonctionnalité , un mécanisme de configuration pour activer ou désactiver les fonctionnalités et le code au moment de l'exécution. Les fonctionnalités qui sont encore en cours de développement sont encapsulées avec des indicateurs de fonctionnalité dans le code, déployées avec la branche principale en production et désactivées jusqu'à ce qu'elles soient prêtes à être utilisées. Selon une enquête récente, 63% des équipes qui utilisent des indicateurs de fonctionnalités signalent de meilleurs tests et des logiciels de meilleure qualité. Les outils de marquage des fonctionnalités tels que CloudBees Rollout, Optimizely Rollouts et LaunchDarkly s'intègrent aux outils CI / CD et permettent des configurations au niveau des fonctionnalités.

Une autre technique de gestion des fonctionnalités est  le branchement du contrôle de version . Une stratégie de branchement telle que Gitflow est sélectionnée pour définir des protocoles sur la façon dont le nouveau code est fusionné dans des branches standard pour le développement, les tests et la production. Des branches de fonctionnalités supplémentaires sont créées pour celles qui nécessiteront des cycles de développement plus longs. Une fois la fonctionnalité terminée, les développeurs peuvent fusionner les modifications des branches de fonctionnalités dans la branche de développement principale. Cette approche fonctionne bien, mais elle peut devenir difficile à gérer si de nombreuses fonctionnalités sont développées simultanément.

Le processus de construction lui-même est ensuite automatisé en empaquetant tous les logiciels, bases de données et autres composants. Par exemple, si vous développiez une application Java, CI regrouperait tous les fichiers statiques du serveur Web tels que HTML, CSS et JavaScript avec l'application Java et tous les scripts de base de données.

CI regroupe non seulement tous les logiciels et composants de base de données, mais l'automatisation exécutera également des tests unitaires et d'autres tests. Ce test fournit aux développeurs des informations indiquant que leurs modifications de code n'ont pas interrompu les tests unitaires existants.

La plupart des outils CI / CD permettent aux développeurs de lancer des builds à la demande, déclenchés par des validations de code dans le référentiel de contrôle de version ou selon un calendrier défini. Les équipes doivent discuter du calendrier de génération qui convient le mieux à la taille de l'équipe, au nombre de validations quotidiennes attendues et à d'autres considérations relatives à l'application. Une bonne pratique pour s'assurer que les validations et les builds sont rapides, sinon, cela peut entraver la progression des équipes essayant de coder rapidement et de s'engager fréquemment.

Les tests continus vont au-delà de l'automatisation des tests

Les cadres de test automatisés aident les ingénieurs d'assurance qualité à définir, exécuter et automatiser divers types de tests qui peuvent aider les équipes de développement à savoir si une version logicielle réussit ou échoue. Ils incluent des tests de fonctionnalité qui sont développés à la fin de chaque sprint et regroupés dans un test de régression pour l'ensemble de l'application. Ces tests de régression informent ensuite l'équipe si une modification de code a échoué à un ou plusieurs des tests développés dans tous les domaines fonctionnels de l'application où il existe une couverture de test.

Une bonne pratique consiste à permettre aux développeurs d'exécuter la totalité ou un sous-ensemble des tests de régression dans leurs environnements locaux et à les obliger. Cette étape garantit que les développeurs ne valident le code au contrôle de version qu'une fois que les tests de régression ont réussi les modifications de code.

Les tests de régression ne sont que le début. Les tests de performance, les tests d'API, l'analyse de code statique, les tests de sécurité et d'autres formulaires de test peuvent également être automatisés. La clé est de pouvoir déclencher ces tests via la ligne de commande, le webhook ou le service Web et qu'ils répondent avec des codes d'état de réussite ou d'échec.

Une fois les tests automatisés, les tests continus impliquent que l'automatisation soit intégrée dans le pipeline CI / CD. Certains tests unitaires et de fonctionnalités peuvent être intégrés dans CI qui signale les problèmes avant ou pendant le processus d'intégration. Les tests qui nécessitent un environnement de livraison complet, tels que les tests de performances et de sécurité, sont souvent intégrés au CD et exécutés après la livraison des builds aux environnements cibles.

Le pipeline CD automatise les modifications apportées à plusieurs environnements

La livraison continue est l'automatisation qui pousse les applications vers les environnements de livraison. La plupart des équipes de développement ont généralement un ou plusieurs environnements de développement et de test dans lesquels les modifications des applications sont préparées à des fins de test et d'examen. Un outil CI / CD tel que Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo ou Travis CI est utilisé pour automatiser les étapes et fournir des rapports.

Un pipeline de CD typique comporte des étapes de création, de test et de déploiement. Les pipelines plus sophistiqués comprennent bon nombre de ces étapes:

  • Extraire le code du contrôle de version et exécuter une compilation.
  • Exécution de toutes les étapes d'infrastructure requises qui sont automatisées sous forme de code pour mettre en place ou démolir l'infrastructure cloud.
  • Déplacement du code vers l'environnement informatique cible.
  • Gérer les variables d'environnement et les configurer pour l'environnement cible.
  • Pousser les composants d'application vers leurs services appropriés, tels que les serveurs Web, les services API et les services de base de données.
  • Exécuter toutes les étapes nécessaires pour redémarrer les services ou appeler les points de terminaison de service nécessaires pour les nouvelles poussées de code.
  • Exécution de tests continus et d'environnements de restauration en cas d'échec des tests.
  • Fournir des données de journal et des alertes sur l'état de la livraison.

Par exemple, les utilisateurs Jenkins définissent leurs pipelines dans un fichier Jenkins qui décrit différentes étapes telles que la construction, le test et le déploiement. Les variables d'environnement, les options, les clés secrètes, les certifications et autres paramètres sont déclarés dans le fichier puis référencés par étapes. La section de publication gère les conditions d'erreur et les notifications.  

Un CD plus sophistiqué peut comporter d'autres étapes telles que l'exécution de synchronisations de données, l'archivage des ressources d'informations ou l'exécution de correctifs d'application et de bibliothèque. Les outils CI / CD prennent généralement en charge un marché de plug-ins. Par exemple, Jenkins répertorie plus de 1 500 plug-ins prenant en charge l'intégration avec des plates-formes tierces, l'interface utilisateur, l'administration, la gestion du code source et la gestion des builds.

Une fois qu'un outil CI / CD est sélectionné, les équipes de développement doivent s'assurer que toutes les variables d'environnement sont configurées en dehors de l'application. Les outils CI / CD permettent de définir ces variables, de masquer les variables telles que les mots de passe et les clés de compte, et de les configurer au moment du déploiement pour l'environnement cible.

Les outils de CD fournissent également des fonctions de tableau de bord et de rapport. Si les builds ou les livraisons échouent, ils alertent les développeurs avec des informations sur les échecs. Ils s'intègrent au contrôle de version et aux outils agiles, de sorte qu'ils peuvent être utilisés pour rechercher les changements de code et les user stories qui ont constitué une build.

Implémentation de pipelines CI / CD avec Kubernetes et des architectures sans serveur 

De nombreuses équipes exploitant des pipelines CI / CD dans des environnements cloud utilisent également des conteneurs tels que Docker et des systèmes d'orchestration tels que Kubernetes. Les conteneurs permettent des applications d'emballage et d'expédition de manière standard et portable. Les conteneurs facilitent la mise à l'échelle ou la destruction d'environnements qui ont des charges de travail variables.

Il existe de nombreuses approches pour utiliser ensemble les conteneurs, l'infrastructure en tant que code et les pipelines CI / CD. Vous pouvez explorer les options en utilisant des didacticiels tels que Kubernetes avec Jenkins ou Kubernetes avec Azure DevOps.

Les architectures informatiques sans serveur offrent une autre voie pour le déploiement et la mise à l'échelle des applications. Dans un environnement sans serveur, l'infrastructure est entièrement gérée par le fournisseur de services cloud et l'application consomme des ressources selon les besoins en fonction de sa configuration. Sur AWS par exemple, les applications sans serveur s'exécutent en tant que fonctions Lambda et les déploiements peuvent être intégrés dans un pipeline Jenkins CI / CD avec un plug-in. 

CI / CD permet des déploiements de code plus fréquents

Pour récapituler, CI package et teste les versions de logiciels et alerte les développeurs si leurs modifications échouent à des tests unitaires. Le CD est l'automatisation qui apporte des modifications à l'infrastructure et exécute des tests supplémentaires. 

Les pipelines CI / CD sont conçus pour les entreprises qui souhaitent améliorer fréquemment leurs applications et nécessitent un processus de livraison fiable. L'effort supplémentaire pour standardiser les builds, développer des tests et automatiser les déploiements est le processus de fabrication pour déployer les changements de code. Une fois en place, il permet aux équipes de se concentrer sur le processus d'amélioration des applications et moins sur les détails du système de livraison aux environnements informatiques.

CI / CD est une bonne pratique de devops car il résout le désalignement entre les développeurs qui souhaitent pousser fréquemment des modifications, avec des opérations qui souhaitent des applications stables. Avec l'automatisation en place, les développeurs peuvent pousser les changements plus fréquemment. Les équipes opérationnelles voient une plus grande stabilité car les environnements ont des configurations standard, des tests continus sont effectués dans le processus de livraison, les variables d'environnement sont séparées de l'application et les procédures de restauration sont automatisées.

L'impact de la mise en œuvre de pipelines CI / CD peut être mesuré comme un indicateur de performance clé (KPI) devops. Les indicateurs clés de performance tels que la fréquence de déploiement, le délai de modification et le temps moyen de récupération (MTTR) d'un incident sont souvent améliorés lorsque CI / CD avec test continu est mis en œuvre. Cependant, CI / CD n'est qu'un processus qui peut conduire ces améliorations, et il existe d'autres conditions préalables à l'amélioration des fréquences de déploiement.

Pour démarrer avec CI / CD, les équipes de développement et les équipes opérationnelles doivent collaborer sur les technologies, les pratiques et les priorités. Les équipes doivent développer un consensus sur les bonnes approches pour leur entreprise et leurs technologies afin qu'une fois CI / CD en place, l'équipe adhère aux pratiques suivantes de manière cohérente.