L'intégration continue et le déploiement continu expliqués (2e Partie)

Pour lire la première partie de ce sujet, cliquez sur ce lien.

Les frameworks de tests automatisés permettent aux ingénieurs de l'assurance qualité de définir, exécuter et automatiser divers types de tests qui peuvent aider les équipes de développement à évaluer leur build. Dans le lot, il y a notamment des tests de fonctionnalité développés à la fin de chaque sprint et regroupés en un test de régression pour l'ensemble de l'application. Grâce à ces tests de régression, l'équipe pourra savoir si une modification du code a échoué à un ou plusieurs tests développés dans tous les domaines fonctionnels de l'application couvert par ces tests. Une bonne pratique consiste à permettre et à exiger des développeurs qu'ils exécutent la totalité ou un sous-ensemble de tests de régression dans leurs environnements locaux. Cette étape garantit que les développeurs ne modifieront le code du contrôle de version que si les modifications de code ont été validés par les tests de régression.

Les tests de régression ne sont qu'un exemple. Il est également possible d’automatiser les tests de performance, les tests d'API, l'analyse de code statique, les tests de sécurité et d'autres formes de tests. L’essentiel est de pouvoir déclencher ces tests soit par ligne de commande, soit par « Webhook », soit à partir d’un service web et qu'ils puissent dire si le code a réussi ou pas. Une fois que les tests sont automatisés, les tests continus impliquent l'intégration de l’automatisation dans le pipeline CI/CD. Certains tests unitaires et de fonctionnalités peuvent être intégrés dans le CI pour signaler des problèmes avant ou pendant le processus d'intégration. Les tests nécessitant un environnement de livraison complet, comme les tests de performance et de sécurité, sont souvent intégrés dans le CD et effectués après la livraison des versions builds aux environnements cibles.

Le pipeline de CD automatise les modifications de plusieurs environnements

La livraison continue (CD) consiste à pousser automatiquement les applications vers des environnements de livraison. La plupart des équipes de développement disposent en général d'un ou plusieurs environnements de développement et de test qu’ils utilisent pour tester et examiner les modifications apportées aux applications dans différents scénarios. Des outils CI/CD comme Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo ou Travis CI sont couramment utilisés pour automatiser les étapes et fournir des rapports.

Un pipeline de déploiement continu typique comporte des étapes de build, de test et de déploiement. Des pipelines plus sophistiqués peuvent comporter plusieurs de ces étapes :

• Extraction du code du contrôle de version et exécution de build.

• Exécution de toutes les étapes d'infrastructure nécessaires, automatisées sous forme de code, pour mettre en place ou démanteler l'infrastructure cloud.

• Déplacement du code vers l'environnement de calcul cible.

• Gestion des variables d'environnement et configuration de ces variables pour l'environnement cible.

• Push des composants d'application vers les services appropriés, comme des serveurs web, des services API et des services de base de données.

• Exécution de toutes les étapes nécessaires pour redémarrer les services ou appeler les points d'extrémité des services nécessaires pour les nouvelles poussées de code.

• Exécution de tests continus et environnements de repli en cas d'échec des tests.

• Fourniture de données de log et d’alertes sur l'état de la livraison.

Par exemple, les utilisateurs de Jenkins définissent leurs pipelines dans un fichier Jenkins qui décrit les différentes étapes comme la build, 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 « Post » de Jenkins gère les conditions d'erreur et les notifications. Les déploiements continus (CD) plus sophistiqués peuvent comporter d'autres étapes comme la synchronisation des données, l'archivage des ressources d'information ou la mise en place de correctifs pour les applications et les bibliothèques. Les outils de CI/CD prennent généralement en charge une boutique de plug-ins. Jenkins répertorie ainsi plus de 1 500 plug-ins pouvant être intégrés avec des plateformes tierces, l'interface utilisateur, l'administration, la gestion du code source et la gestion de la build.

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 des variables comme 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 CD offrent également des fonctions de tableau de bord et de reporting. En cas d'échec des builds ou des livraisons, ces outils alertent les développeurs en leur fournissant des informations sur les défaillances. Comme ils s'intègrent au contrôle de version et aux outils agiles, ils peuvent être utilisés pour rechercher les modifications de code et l’historique des utilisateurs ayant participé à la build.

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

Beaucoup d’équipes exploitant des pipelines de CI/CD dans des environnements cloud utilisent également des conteneurs comme Docker et des systèmes d'orchestration comme Kubernetes. Les conteneurs permettent de packager et de livrer des applications de manière standard et portable. Les conteneurs permettent de mettre à l'échelle ou de démanteler facilement des environnements dont les workloads sont variables. Il existe de nombreuses approches pour utiliser ensemble les conteneurs, l'infrastructure comme code et les pipelines de CI/CD. Des tutoriels comme Kubernetes with Jenkins ou Kubernetes with Azure DevOps permettent d’explorer les différentes approches.

Les architectures serverless représentent une autre option de déploiement et de mise à l'échelle des applications. Dans un environnement serverless, 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 serverless sont exécutées comme des fonctions Lambda et les déploiements peuvent être intégrés dans un pipeline de CI/CD Jenkins avec un plug-in.

Des déploiements de code plus fréquents

Pour résumer, l’intégration continue (CI) permet de packager et de tester les builds et d’alerter les développeurs si les modifications apportées au code n’ont pas passé les tests unitaires. Le déploiement continu (CD) est un processus d’automatisation qui délivre les changements à l'infrastructure et exécute des tests supplémentaires. Les pipelines CI/CD sont destinés aux entreprises qui souhaitent améliorer fréquemment leurs applications et qui ont besoin d'un processus de livraison fiable. Le travail supplémentaire de normalisation des builds, de développement des tests et d’automatisation des déploiements entre dans le processus de déploiements des changements de code. Une fois mis en place, il permet aux équipes de se concentrer davantage sur l'amélioration des applications et moins sur les détails de livraison aux environnements IT.

Le CI/CD est une meilleure pratique devops, car elle résout le problème de décalage qu’il peut y avoir entre les développeurs qui veulent pousser les changements fréquemment, et les équipes opérationnelles qui veulent des applications stables. L’automatisation permet aux développeurs de pousser les changements de code plus fréquemment. Les équipes opérationnelles constatent une plus grande stabilité parce que les environnements ont des configurations standards, parce que le processus de livraison est testé en permanence, que les variables d'environnement sont séparées de l'application et que les procédures de repli sont automatisées.

La méthode avant tout

Il est possible de mesurer l'impact de l’implémentation de pipelines de CI/CD à l’aide d’indicateurs clés de performance (KPI) devops. Par exemple, la fréquence de déploiement, le délai de changement et le délai moyen de rétablissement (MTTR) après un incident sont souvent améliorés quand une implémentation CI/CD avec test continu a été mise en œuvre. Cependant, le CI/CD n'est que l’un des processus pouvant contribuer à ces améliorations. D'autres préalables sont également nécessaires pour améliorer la fréquence de déploiement. Avant de commencer à utiliser des pipelines de CI/CD, les équipes de développement et les équipes opérationnelles doivent collaborer sur les technologies, les pratiques et les priorités. Elles doivent s’entendre sur les meilleures approches pour leurs activités et leurs technologies et s'engager à suivre les pratiques de manière cohérente quand le CI/CD est en place.