Comprendre les pipelines de CI/CD
Si vous vous intéressez à l'intégration, la livraison et le déploiement continus (connus sous le nom de CI/CD), vous avez certainement rencontré le terme de « pipeline automatisé » et découvert le rôle central qu'il joue dans l'implémentation de ces pratiques. Mais qu'est-ce exactement qu'un pipeline d'intégration continue et de livraison continue ? Et comment en construire un ?
L'objectif du CI/CD est de réduire le temps nécessaire à la livraison des logiciels aux utilisateurs, sans compromettre la qualité. Pour ce faire, vous devez vérifier fréquemment les modifications, les tester rigoureusement et traiter rapidement les retours, afin de pouvoir déployer vos modifications aussi souvent que vous le souhaitez.
Qu'est-ce qu'un pipeline de CI/CD ?
Un pipeline de CI/CD désigne une série d'étapes par lesquelles votre code passe pour aller de votre système de développement à votre communauté d'utilisateurs, en passant par des tests et des étapes intermédiaires.
Comme la stratégie de CI/CD consiste à exécuter ce processus de manière très régulière (généralement plusieurs fois par jour), il est essentiel d'en automatiser la plus grande partie possible, chaque étape déclenchant la suivante ou un signal si un problème est rencontré.
L'automatisation permet non seulement d'accélérer le processus global, et donc les boucles de feedback, mais aussi de garantir que chaque étape est exécutée de manière cohérente et fiable.
Les étapes d'un pipeline de build
Bien que le format exact de votre pipeline de CI/CD dépende du type de produit que vous développez, ainsi que des besoins de votre entreprise, il existe un modèle standard que tous les pipelines tendent à suivre, présenté ci-dessous.
En règle générale, il faut commencer par faire un commit sur le master (ou vers la branche que vous avez désignée comme branche CI), qui déclenche soit une build, soit une série initiale de tests unitaires. Les résultats sont renvoyés vers un tableau de bord. Si le build ou un test échoue, vous recevez une notification automatique.
Vous pouvez soit configurer le pipeline pour arrêter le processus afin de résoudre le problème et recommencer avec un nouveau commit, soit créer des exceptions pour des cas particuliers d'échec et poursuivre le processus.
L'étape suivante consiste en une série de tests automatisés, avec un retour d'information après chaque test. En général, les tests sont organisés de manière à ce que les tests les plus rapides soient exécutés en premier pour obtenir un retour d'information le plus tôt possible.
Les tests plus complexes qui mobilisent les serveurs pendant plus longtemps, tels que les tests de bout en bout, ne sont exécutés que lorsque les tests précédents ont été réussis. Les ressources sont ainsi utilisées de manière plus efficace.
Une fois les tests automatisés terminés, le logiciel est généralement déployé dans une série d'environnements intermédiaires, dont certains peuvent être utilisés pour des tests manuels supplémentaires et d'autres pour former, assister ou les versions d'évaluation client.
La dernière étape d'architecture du pipeline CI/CD consiste à déployer les modifications en ligne. Elle peut être déclenchée manuellement (dans le cas d'une livraison continue) ou automatiquement (dans le cas d'un déploiement continu).
Examinons maintenant de plus près certains aspects de ces étapes.
Indicateurs et branches
La première étape de l'implémentation de l'intégration continue consiste à transférer l'ensemble de votre base de données dans un système de contrôle de version (VCS, également appelé gestion du contrôle de code source ou SCM), tel que Git, Mercurial ou Perforce. Ensuite, vous devez amener tous les membres de votre équipe à effectuer fréquemment des commits de leurs modifications. Chaque commit sur le master déclenche une exécution du pipeline : le code est compilé et testé pour vous fournir un retour rapide sur vos modifications.
Bien que les commits fréquents constituent une pratique importante dans le pipeline de CI/CD, si vous travaillez sur une fonctionnalité plus importante qui prend plusieurs jours ou semaines à terminer, envoyer périodiquement des commits pendant ce processus peut être une arme à double tranchant.
En introduisant vos modifications dans le pipeline à intervalles réguliers, vous obtenez un retour d'information plus rapide et réduisez la probabilité de conflits complexes par rapport à une vérification unique à la fin du processus.
D'autre part, vous ne souhaitez probablement pas proposer aux utilisateurs une fonctionnalité à moitié terminée, ni partager vos travaux en cours avec des utilisateurs internes via des environnements intermédiaire.
Les indicateurs de fonctionnalités et les branches de fonctionnalité permettent de contourner ce problème. Les indicateurs de fonctionnalités vous permettent de spécifier les environnements dans lesquels vous souhaitez que votre code soit visible. Vos modifications sont toujours enregistrées dans le master et visibles par votre équipe, mais c'est vous qui décidez quand la fonctionnalité devient disponible en préproduction et en production.
Les branches de fonctionnalité vous permettent de développer votre fonctionnalité dans une branche distincte, sans perdre les avantages du build et des tests automatisés. En déclenchant le pipeline de CI/CD à chaque commit sur une branche de fonctionnalité (comme pour un commit sur le master), vous obtenez des retours rapides sur votre projet.
Créer et tester
Après avoir déclenché une instance de votre pipeline avec un commit, les étapes suivantes sont le build et les tests. Si vous avez des tests unitaires automatisés, ils sont généralement exécutés avant la création d'un build avec le linting et les vérifications d'analyse statique.
L'outil de build que vous utilisez (comme Ant ou Maven) et les détails des étapes de build dépendent du langage et du framework dans lesquels vous travaillez. En exécutant le build automatisé sur un serveur de build dédié, vous pouvez éviter les problèmes en aval causés par des dépendances manquantes : le problème classique du « ça marche sur mon PC ».
Le résultat de l'étape de build comprend les programmes d'installation, les binaires ou les conteneurs (les artefacts de build), qui sont ensuite déployés dans des environnements de test et combinés avec d'autres parties du système pour exécuter des tests automatisés de niveau supérieur : tests d'intégration, tests de composants et tests de bout en bout, ainsi que des tests non fonctionnels, tels que l'analyse des performances et de la sécurité.
Ces tests peuvent être exécutés en parallèle pour accélérer le processus et vous fournir un retour d'information plus rapide.
Conteneurs et VMs
Pour que les résultats de vos tests automatisés soient fiables, vous devez vous assurer qu'ils s'exécutent de manière cohérente.
Idéalement, vos environnements de test doivent être configurés de manière à être aussi similaires que possible à l'environnement de production, et ils doivent être réinitialisés entre les tests pour éviter que les incohérences environnementales ne perturbent les résultats de vos tests.
Les machines virtuelles (VM) sont depuis longtemps un choix populaire pour l'exécution des environnements de test, car vous pouvez programmer l'environnement pour qu'il se réinitialise à chaque nouveau build.
Cependant, arrêter et lancer de nouvelles machines virtuelles prend du temps, et vos scripts doivent inclure une configuration pour chaque environnement virtuel afin de fournir toutes les dépendances nécessaires à l'exécution du logiciel. Lorsque de nouvelles dépendances sont ajoutées, les scripts d'environnement doivent être mis à jour. Attention à ne pas oublier ce point, car cela peut empêcher l'exécution du build.
Vous pouvez éviter ces problèmes en intégrant votre code dans un conteneur lors de l'étape initiale de build. Un conteneur comprend toutes les dépendances dont le logiciel a besoin pour fonctionner, ce qui lui confère une grande portabilité et facilite son déploiement dans différents environnements.
Si vous hébergez votre processus de CI/CD sur votre propre infrastructure, des machines virtuelles seront toujours nécessaires pour déployer les conteneurs, mais la préparation de l'environnement de test nécessite moins d'efforts, résultant ainsi à un pipeline plus efficace. Si vous exécutez votre pipeline dans le cloud, vous pouvez tirer parti des services gérés en utilisant des conteneurs et externaliser l'ensemble de l'infrastructure à votre fournisseur cloud.
Environnements de pré-production
Le nombre d'environnements de test et de préproduction dans l'architecture de votre pipeline dépend de votre produit et des exigences des parties prenantes de votre organisation. Par exemple, il peut s'agir de tests exploratoires, d'analyses de sécurité, de recherches relatives aux utilisateurs, de démonstrations de vente, d'environnements de formation et de sandboxes permettant au personnel chargé de l'assistance de reproduire les problèmes des clients.
La création et le déploiement automatisés de ces environnements sont plus efficaces que leur actualisation manuelle, et vous pouvez configurer différents déclencheurs de pipeline pour différents environnements.
Par exemple, alors que vos environnements de test peuvent être mis à jour à chaque build, vous pouvez décider d'actualiser les environnements intermédiaires moins fréquemment (éventuellement une fois par jour ou par semaine avec le dernier build réussi).
Déployer
Lorsque vos modifications de code ont réussi toutes les étapes précédentes du pipeline, elles sont prêtes pour la mise en production. Cette étape finale peut être manuelle ou automatique.
La publication manuelle (connue sous le nom de livraison continue) est utile si vous voulez contrôler quand ces nouvelles fonctionnalités sont mises à disposition, si votre processus de déploiement implique des temps d'arrêt pour vos utilisateurs, ou si votre produit est installé et que vous voulez regrouper les modifications et les déployer selon un calendrier de sortie périodique.
Grâce à un processus de déploiement continu entièrement automatisé, les modifications sont déployées dès lors qu'elles ont réussi toutes les étapes précédentes.
En fonction du nombre de développeurs travaillant sur la base de code et la fréquence de leurs commits, vous pouvez être amené à déployer des mises à jour pour les utilisateurs des dizaines de fois par jour, ce qui est pratiquement impossible sans pipeline automatisé.
Comprendre les pipelines de CI/CD : en résumé
Le CI/CD rend le développement de logiciels plus efficace en identifiant les problèmes le plus tôt possible. Cette méthode vous permet de faire des erreurs plus rapidement en déclenchant des interactions plus vite et en obtenant des retours d'information plus tôt (la méthodologie du déplacement à gauche). La création d'un pipeline automatisé vous aide à mettre ces techniques en pratique.
Lorsque vous concevez votre propre processus de CI/CD, il est utile de le développer par étapes, en commençant par l'intégration continue. Les étapes exactes du pipeline et la logique qui détermine à quel moment chaque étape est déclenchée dépendent de votre produit et de votre organisation.
Choisir une plateforme de CI/CD qui vous offre la souplesse nécessaire pour configurer votre pipeline en fonction de vos besoins, tout en étant facile à gérer, vous aidera à mettre en place un processus de publication fiable et à améliorer la qualité de vos logiciels.