CI/CD
Qu'est-ce que le CI/CD ?
CI/CD, ou intégration continue/livraison continue ou déploiement, est une pratique de développement logiciel rendue possible par l'automatisation. Des mises à jour fréquentes et fiables accélèrent les cycles de publication grâce à la livraison continue de code.
CI/CD expliqué
CI/CD est un terme générique couvrant plusieurs phases de DevOps. CI (intégration continue) est la pratique d'intégrer des modifications de code dans un dépôt plusieurs fois par jour. CD a deux significations : La livraison continue automatise les intégrations de code, tandis que le déploiement continu libère automatiquement les versions finales aux utilisateurs finaux. Les tests fréquents de CI/CD réduisent les erreurs et les défauts de code, ce qui est crucial pour chaque flux de travail DevOps.
Qu'est-ce que l'intégration continue ? (CI)
L'intégration continue (CI) est un processus de développement logiciel automatisé qui augmente la vitesse de développement tout en garantissant un code propre et de qualité à chaque déploiement. L'intégration continue nécessite que les développeurs enregistrent/commettent fréquemment leurs unités de code dans un dépôt central partagé plusieurs fois par jour.
CI est une meilleure pratique DevOps et une étape dans le cycle de vie DevOps lorsque les développeurs enregistrent le code dans leur dépôt de code partagé. Un outil de construction automatisé vérifie l'enregistrement ou la branche pour s'assurer qu'il n'y a pas d'erreurs et qu'il est prêt à être mis en production. Le principal avantage ici est que les problèmes sont généralement détectés tôt avant qu'ils ne puissent se transformer en problèmes plus importants.
Pratiquer l'intégration continue signifie intégrer de petits sous-ensembles de modifications dans un délai plus court, plutôt que des mises à jour substantielles qui prennent plus de temps et sont moins fréquentes. L'automatisation des flux de travail pour les tests, la fusion et l'enregistrement des modifications dans un dépôt partagé signifie que les équipes peuvent livrer un code plus propre à un rythme plus rapide. Un code plus propre signifie une validation plus rapide, des versions de meilleure qualité et un pipeline de développement plus efficace qui est plus facile à mettre à l'échelle.
Comment fonctionne l'intégration continue ?
L'intégration continue est un processus simple et fluide qui commence dans la phase de développement et se termine dans l'environnement de test. L'intégration continue permet à tous les développeurs de travailler en collaboration et de suivre leur code. Chaque développeur "commet" son code par petites incréments dans un dépôt de code partagé, également connu sous le nom de dépôt principal. Le dépôt de code est maintenu dans un système de contrôle de version comme Unity VCS, Perforce ou Git. Chaque commit effectué sur la branche principale du dépôt (ou sur des branches enfants si vous le choisissez) peut déclencher un processus de construction automatisé lié à un système de gestion de construction qui prend le code et crée une construction. Une fois le code fusionné dans le système de construction, les développeurs ont un accès complet à leurs constructions de code. À partir de là, ils peuvent voir si leur code est compilé correctement ou s'il y a une erreur qu'ils pourraient avoir besoin de corriger. Les systèmes de construction peuvent être configurés pour prendre en charge divers cadres de test.
Une fois le code approuvé et le cycle de construction réussi, un environnement de test automatisé est déclenché pour valider la qualité de la construction et de la version suivante. Parce que le processus de test et de construction est extrêmement rapide, les résultats des commits de code peuvent être communiqués rapidement, permettant aux développeurs de corriger toute erreur restante en temps opportun. Tout ce processus garantit que la base de code reste saine et que tout le monde peut continuer à travailler efficacement.
Règles et principes de l'intégration continue
- Maintenir un dépôt de code central
Le stockage temporaire de code provenant de différents développeurs dans diverses équipes dans des dépôts ou systèmes séparés doit être réduit au minimum.
- Commiter/enregistrer le code dans le dépôt principal fréquemment
Plus un développeur conserve du code sans le construire ou le tester, plus il est probable qu'il soit incohérent avec ce qui est stocké dans le dépôt central.
- Maintenir des serveurs de construction et de test séparés
Les équipes doivent maintenir des machines dédiées uniquement à des fins de construction. Cela accélère le processus de construction et minimise l'impact sur les flux de travail des autres développeurs.
- Les constructions et les tests doivent être automatisés
Chaque morceau de code commis dans le dépôt de code source central doit être construit et testé automatiquement avec des outils d'intégration continue.
- Utiliser des environnements de test similaires à la production
Les environnements de test doivent simuler l'environnement de production final. Cela garantit l'utilité de l'environnement de test et maintient des attentes cohérentes tout au long du déploiement.
- Les équipes d'assurance qualité doivent avoir accès aux constructions
Lorsque l'assurance qualité a accès aux constructions, tout échec à répondre aux exigences de production peut être détecté tôt, réduisant le risque de devoir retravailler les constructions de code plus tard.
Livraison continue vs déploiement continu
Le déploiement continu et la livraison continue sont des pratiques utilisées pour prendre du nouveau code et le pousser en production aussi rapidement et efficacement que possible. La livraison continue suit l'intégration continue - vous pouvez la considérer comme une phase de point de contrôle dans le pipeline de développement avant que le produit final ne soit livré aux clients. Une fois que les modifications de code ont été validées, elles sont automatiquement livrées au dépôt central.
Le déploiement continu suit l'intégration continue dans le cycle de vie DevOps, mais les deux processus sont liés. L'intégration continue intègre le code dans la construction avec automatisation ; la livraison continue complète ce processus. Les automatisations DevOps évaluent la qualité des mises à jour. Une fois qu'elles ont été jugées exemptes d'erreurs, elles sont automatiquement déployées en production.
Qu'est-ce que la livraison continue ?
La livraison continue fait référence à la construction, aux tests et à la livraison des modifications de code au logiciel. Dans ce processus, le code passe par divers environnements de test, tels que les tests unitaires automatisés, les tests d'intégration et les tests système, avant d'être poussé en production. La livraison continue se produit dans des environnements de staging similaires à la production où les QA examinent le code, corrigent les bogues et exécutent des tests automatisés pour s'assurer que les constructions sont toujours déployables et prêtes à être publiées.
Avec la livraison continue, l'objectif est de garder les ensembles de modifications suffisamment petits pour qu'aucune mise à jour de la construction principale ne compromette le statut « prêt pour la production » du produit final. Le produit final peut contenir des erreurs mineures, mais rien de suffisamment substantiel pour compromettre l'expérience utilisateur.
Pratiquer la livraison continue signifie que les développeurs peuvent passer moins de temps à tester en interne, car la pratique garantit que seul le code stable atteint la phase de livraison en premier lieu. Cela rend la détection des bogues un processus plus simple, accélérant le temps de résolution.
Qu'est-ce que le déploiement continu ?
Le déploiement continu vise à déployer en continu les modifications de code en production à partir du dépôt central une fois que la construction est stable. L'équipe des opérations déploie le code compilé et installe le logiciel dans différents environnements (dev/test, staging et production). Chaque changement passe par un pipeline automatisé qui pousse une version fonctionnelle de l'application en production. Le déploiement peut prendre différentes formes. Un déploiement caché est un déploiement qui est caché des utilisateurs, tandis que les commutateurs de fonctionnalités ou les interrupteurs peuvent être utilisés pour déployer des sous-ensembles spécifiques d'un ensemble de modifications à un groupe d'utilisateurs pour des tests et des retours.
Le déploiement continu présente de nombreux avantages pour les développeurs et les clients. Les développeurs utilisant des solutions de déploiement continu n'ont plus besoin de se soucier du déploiement manuel des builds et peuvent se concentrer sur des tâches plus basées sur les compétences. L'automatisation raccourcit les boucles de rétroaction, ce qui signifie que les produits peuvent être mis à jour plus rapidement en fonction des retours des clients. Avec le déploiement continu, le code est exécuté et maintenu dans un environnement simulé qui garantit la qualité et permet une surveillance en temps réel du produit. L'objectif principal du déploiement continu est de publier de nouvelles versions du code de manière cohérente et de déployer automatiquement ces changements aux utilisateurs finaux.
Comment le CI/CD et le DevOps sont-ils liés ?
Tout développement logiciel commence par la préproduction (la phase de planification), suivie de la production (codage et création d'actifs). Le DevOps est une culture et un processus visant à rendre ces processus plus efficaces. Le CI/CD est une phase au sein du cycle de vie DevOps qui impose la mise en œuvre de flux de mises à jour de code petits mais réguliers au fil du temps pour garantir une amélioration continue et itérative du produit final.
Des versions logicielles régulières et fréquentes peuvent être obtenues en utilisant des outils et des produits spécifiques pour permettre l'intégration, la livraison et le déploiement des changements de code - cela s'appelle un pipeline CI/CD.
Un pipeline CI/CD est un ensemble spécifique de phases lié à des outils et à l'automatisation qui permet au cycle de vie DevOps de se réaliser. Bien que le CI/CD soit une partie intégrante d'une culture DevOps, le DevOps englobe beaucoup plus tout au long du cycle de vie du développement logiciel - de la collaboration à la structure de l'équipe, à l'observabilité, au contrôle de version, et plus encore.
La mise en œuvre du DevOps varie considérablement d'une organisation à l'autre, mais au fond, le DevOps ne peut être accompli sans CI/CD. Un pipeline CI/CD est intrinsèquement lié à une culture DevOps et à son processus de petites versions fréquentes.
Avantages du CI/CD
- Itération rapide
L'adoption des pratiques CI/CD dans le cadre de votre cycle de vie DevOps accélère le développement en automatisant le travail manuel de validation et de déploiement des modifications dans la base de code.
- Code plus propre
En enregistrant de nombreux petits changements tout au long de la journée, on réduit considérablement le risque d'introduction d'erreurs qui cassent la construction dans votre code source.
- Corrections de bogues plus rapides
Fusionner des ensembles de changements plus petits plus souvent avec CI/CD facilite l'identification des erreurs de code et leur correction avant qu'elles ne deviennent un problème plus important.
- Boucles de rétroaction plus courtes
CI/CD aide à raccourcir les boucles de rétroaction – un principe fondamental DevOps – car les changements plus petits et itératifs sont plus faciles à intégrer, tester et déployer.
- Meilleure collaboration
CI/CD apporte de la clarté au travail en définissant des processus et des délais pour les engagements de code et les lancements de construction. Avec des objectifs plus clairs, les équipes peuvent agir avec plus d'agilité.
- Clients plus satisfaits
Parce que les constructions sont toujours prêtes à être publiées avec CI/CD, les clients subissent moins d'interruptions de service, et leurs retours peuvent être intégrés beaucoup plus rapidement.
L'agilité est-elle la même chose que CI/CD ?
Un flux de travail agile et CI/CD sont liés, cependant, ils ne sont pas identiques ! Ils décrivent des aspects complètement différents du pipeline de développement logiciel. Le développement agile fait référence aux processus ou méthodologies pour gérer les flux de travail, les cadences de réunion et l'organisation des équipes dans le développement logiciel. Une méthodologie agile embrasse le changement tout en accélérant la livraison en écoutant et en répondant aux besoins des clients et en les impliquant à chaque étape du processus de développement.
CI/CD repose sur l'automatisation pour éliminer les éléments humains qui créent des goulets d'étranglement dans la publication et l'amélioration du logiciel. Dans les tests CI et CD, l'automatisation est présente tout au long du pipeline et se fait fréquemment pour minimiser les coûts et le temps nécessaire pour remédier aux défauts.
À quelle fréquence devez-vous déployer en production avec le déploiement continu ?
Avec CI/CD, les versions doivent toujours être fréquentes pour éviter de futurs problèmes et garantir que votre logiciel est toujours dans un état publiable - généralement en déployant plusieurs fois par jour. Une hypothèse courante avec les équipes CI/CD est de mettre en œuvre des versions "constantes", cependant, ce n'est pas toujours le cas. Votre cycle de publication peut varier considérablement en fonction de votre produit, de vos builds et d'autres facteurs que vous pourriez vouloir prendre en compte, tels que :
1. S'agit-il d'un correctif critique ou mineur ?
2. Suivez-vous les comptes de régression d'une build à l'autre ?
3. Y a-t-il une équipe QA mise en place ?
4. La base de code a-t-elle des tests unitaires ?
5. Y a-t-il des duplications de code ?
Ce ne sont que quelques exemples d'aspects à considérer lors de la réflexion sur une stratégie de publication et un pipeline, mais cela diffère considérablement d'une équipe à l'autre. Différents produits nécessitent différentes approches.
Le déploiement continu en vaut-il la peine ?
Il n'y a pas de réponse unique à cette question. Avant d'investir dans le déploiement continu, une entreprise doit d'abord évaluer quels sont les plus grands risques de son produit, puis déterminer les compromis sur la manière dont vous souhaitez déployer le logiciel.
Le succès de votre produit dépend de votre capacité à itérer rapidement, à obtenir des retours de vos clients et à continuer à apporter des modifications. Le déploiement continu aura un impact considérable et sera rentable si vous priorisez le raccourcissement des boucles de rétroaction et la construction d'une entreprise très réactive.
Cependant, si votre entreprise n'a pas beaucoup de clients, les avantages de la mise en œuvre d'incréments de déploiement ajouteront moins de valeur et plus de coûts. L'environnement de staging que vous choisissez de déployer dépend finalement des besoins de votre entreprise, de votre flux de travail et de votre budget.
La livraison continue encourage la configuration car elle apporte en continu des modifications au code original dans la configuration. Cela garantit que la configuration reste à jour avec les erreurs de code qui peuvent survenir au fil du temps.