Plan du site  
pixel
pixel

Articles - Étudiants SUPINFO

Une introduction à l'intégration, à la livraison et au déploiement continus

Par Metomo JOSEPH BERTRAND RAPHAËL Publié le 30/11/2017 à 22:22:59 Noter cet article:
(0 votes)
Avis favorable du comité de lecture

Introduction

Développer et livrer des logiciels peut être un processus compliqué, d'autant plus que les applications, les équipes et l'infrastructure de déploiement augmentent elles-mêmes en complexité. Souvent, les défis deviennent plus prononcés à mesure que les projets grandissent. Pour développer, tester et publier des logiciels de manière rapide et cohérente, les développeurs et les organisations ont créé trois stratégies complémentaires mais distinctes pour gérer et automatiser ces processus.

L'intégration continue met l'accent sur l'intégration du travail des développeurs individuels dans un référentiel principal plusieurs fois par jour pour détecter rapidement les bogues d'intégration et accélérer le développement collaboratif. La livraison continue consiste à réduire les frictions dans le processus de déploiement ou de publication, en automatisant les étapes requises pour déployer une version afin que le code puisse être publié en toute sécurité à tout moment. Le déploiement continu va encore plus loin en déployant automatiquement chaque fois qu'un changement de code est effectué.

Dans cet article, nous allons discuter de chacune de ces stratégies, de leur relation et de leur intégration dans le cycle de vie des applications, ce qui peut transformer vos pratiques de développement et de publication de logiciels.

Qu'est-ce que l'intégration continue et pourquoi est-ce utile?

L'intégration continue est une pratique qui encourage les développeurs à intégrer tôt et régulièrement leur code dans une branche principale d'un référentiel partagé. Au lieu de construire des fonctionnalités isolément et de les intégrer à la fin d'un cycle de développement, le code est intégré au référentiel partagé par chaque développeur plusieurs fois au cours de la journée.

L'idée est de minimiser le coût de l'intégration en en faisant une première évaluation. Les développeurs peuvent détecter rapidement les conflits entre les nouveaux codes et les codes existants, tandis que les conflits sont encore relativement faciles à réconcilier. Une fois le conflit résolu, le travail peut continuer avec la certitude que le nouveau code respecte les exigences de la base de code existante.

L'intégration du code n'offre généralement pas de garantie quant à la qualité du nouveau code ou de la nouvelle fonctionnalité. Dans de nombreuses organisations, l'intégration est coûteuse car les processus manuels sont utilisés pour garantir que le code respecte les normes, n'introduit pas de bogues et ne casse pas les fonctionnalités existantes. Une intégration fréquente peut créer des frictions lorsque le niveau d'automatisation ne correspond pas aux mesures d'assurance qualité en place.

Pour remédier à cette friction dans le processus d'intégration, en pratique, l'intégration continue repose sur des suites de tests robustes et un système automatisé pour exécuter ces tests. Lorsqu'un développeur fusionne le code dans le référentiel principal, les processus automatisés déclenchent la création du nouveau code. Ensuite, les tests sont exécutées sur la nouvelle version pour vérifier si des problèmes d'intégration ont été introduits. Si la phase de construction ou de test échoue, l'équipe est alertée afin de pouvoir corriger la construction.

L'objectif final de l'intégration continue est de faire de l'intégration un processus simple et reproductible qui fait partie du processus de développement quotidien afin de réduire les coûts d'intégration et de répondre rapidement aux défauts. Travailler pour s'assurer que le système est robuste, automatisé et rapide, tout en cultivant une culture d'équipe qui encourage une itération fréquente et une réactivité pour résoudre les problèmes est essentiel au succès de la stratégie.

Qu'est-ce que la livraison continue et pourquoi est-ce utile?

La livraison continue est une extension de l'intégration continue. Il se concentre sur l'automatisation du processus de livraison de logiciels afin que les équipes puissent déployer facilement et en toute confiance leur code en production à tout moment. En veillant à ce que la base de code soit toujours dans un état déployable, Publierr le logiciel devient un événement banal sans rituel compliqué. Les équipes peuvent être confiantes qu'elles peuvent livrerr chaque fois qu'elles en ont besoin, sans coordination complexe ni test en phase avancée. Comme pour l'intégration continue, la livraison continue est une pratique qui nécessite un mélange d'améliorations techniques et organisationnelles pour être efficace.

Du côté de la technologie, la livraison continue s'appuie fortement sur les pipelines de déploiement pour automatiser les processus de test et de déploiement. Un pipeline de déploiement est un système automatisé qui exécute des suites de tests de plus en plus rigoureuses par rapport à une construction en une série d'étapes séquentielles. Cela décolle lorsque l'intégration continue s'interrompt, donc une configuration d'intégration continue fiable est une condition préalable à la mise en œuvre de la livraison continue.

À chaque étape, la construction échoue aux tests, ce qui alerte l'équipe, ou passe les tests, ce qui entraîne une promotion automatique à l'étape suivante. Au fur et à mesure que la construction se déplace dans le pipeline, les étapes ultérieures déploient la génération dans des environnements qui reflètent l'environnement de production aussi étroitement que possible. De cette façon, la construction, le processus de déploiement et l'environnement peuvent être testés en tandem. Le pipeline se termine par une construction qui peut être déployée en production à tout moment en une seule étape.

Les aspects organisationnels de la prestation continue encouragent la priorisation de la «déployabilité» en tant que préoccupation principale. Cela a un impact sur la façon dont les fonctionnalités sont construites et accrochées dans le reste de la base de code. Il faut réfléchir à la conception du code afin que les fonctionnalités puissent être déployées en toute sécurité à tout moment, même lorsqu'elles sont incomplètes. Un certain nombre de techniques ont émergé pour aider dans ce domaine.

La livraison continue est intéressante car elle automatise les étapes entre la vérification du code dans le référentiel et la décision de publier des builds fonctionnels et bien testés sur votre infrastructure de production. Les étapes qui permettent d'affirmer la qualité et l'exactitude du code sont automatisées, mais la décision finale sur ce qu'il faut publier est laissée entre les mains de l'organisation pour une flexibilité maximale.

Qu'est-ce que le déploiement continu et pourquoi est-il utile?

Le déploiement continu est une extension de la distribution continue qui déploie automatiquement chaque build qui passe le cycle de test complet. Au lieu d'attendre qu'un gatekeeper humain décide du moment du déploiement en production, un système de déploiement continu déploie tout ce qui a réussi à traverser le pipeline de déploiement. Gardez à l'esprit que bien que le nouveau code soit automatiquement déployé, des techniques existent pour activer de nouvelles fonctionnalités à un moment ultérieur ou pour un sous-ensemble d'utilisateurs. Le déploiement propulse automatiquement les fonctionnalités et les correctifs vers les clients, encourage les modifications plus petites avec une portée limitée et évite toute confusion sur ce qui est actuellement déployé en production.

Ce cycle de déploiement entièrement automatisé peut être une source d'anxiété pour les organisations qui s'inquiètent d'abandonner le contrôle de leur système d'automatisation sur ce qui est publié. Le compromis offert par les déploiements automatisés est parfois jugé trop dangereux pour la récompense qu'ils fournissent.

D'autres groupes tirent parti de la promesse de la publication automatique comme moyen de s'assurer que les meilleures pratiques sont toujours suivies et d'étendre le processus de test dans un environnement de production limité. Sans une vérification manuelle finale avant de déployer un morceau de code, les développeurs doivent prendre la responsabilité de s'assurer que leur code est bien conçu et que les suites de tests sont à jour. Cela efface la décision de quoi et quand s'engager dans le référentiel principal et quoi et quand livrer vers la production dans un seul point qui existe fermement entre les mains de l'équipe de développement.

Le déploiement continu permet également aux organisations de bénéficier d'une rétroaction rapide et cohérente. Les fonctionnalités peuvent être immédiatement mises à la disposition des utilisateurs et des défauts ou des implémentations inutiles peuvent être détectés tôt avant que l'équipe ne consacre des efforts considérables dans une direction improductive. Obtenir une rétroaction rapide sur le fait qu'une fonctionnalité n'est pas utile permet à l'équipe de changer d'orientation plutôt que de dépenser plus d'énergie dans une zone avec un impact minimal.

Concepts et pratiques clés pour les processus continus

Bien que l'intégration, la livraison et le déploiement continus varient dans la portée de leur participation, certains concepts et pratiques sont essentiels au succès de chacun.

Petites modifications itératives

L'une des pratiques les plus importantes lors de l'adoption de l'intégration continue est d'encourager de petits changements. Les développeurs doivent s'entraîner à diviser un travail plus important en petits morceaux et à les soumettre tôt. Des techniques spéciales telles que la dérivation par abstraction et les drapeaux d'entités (voir ci-dessous) aident à protéger la fonctionnalité de la branche principale contre les changements de code en cours.

Les petits changements minimisent la possibilité et l'impact des problèmes d'intégration. En s'engageant sur la branche partagée le plus tôt possible, puis continuellement tout au long du développement, le coût de l'intégration est diminué et le travail indépendant est synchronisé régulièrement.

Développement basé sur le tronc

Avec le développement basé sur le tronc, le travail est effectué dans la branche principale du référentiel ou fusionné dans le référentiel partagé à intervalles fréquents. Les branches à courte durée de vie sont autorisées à condition qu'elles représentent de petits changements et qu'elles soient fusionnées le plus rapidement possible.

L'idée derrière le développement basé sur le tronc est d'éviter les grands commits qui violent le concept de petits changements itératifs présenté ci-dessus. Le code est disponible tôt pour les pairs afin que les conflits puissent être résolus lorsque leur portée est réduite.

Les rejets sont effectués à partir de la branche principale ou à partir d'une branche de publication créée à partir du tronc spécifiquement à cette fin. Aucun développement ne se produit sur les branches de déploiement afin de maintenir l'accent sur la branche principale en tant que source unique de vérité.

Gardez les phases de construction et de test rapide

Chacun des processus repose sur la construction et les tests automatisés pour valider l'exactitude. Étant donné que les étapes de construction et de test doivent être effectuées fréquemment, il est essentiel que ces processus soient rationalisés afin de minimiser le temps passé sur ces étapes.

Les augmentations du temps de construction devraient être traitées comme un problème majeur, car l'impact est aggravé par le fait que chaque validation déclenche une construction. Parce que les processus continus forcent les développeurs à s'engager quotidiennement dans ces activités, la réduction des frictions dans ces domaines est une poursuite valable.

Lorsque cela est possible, l'exécution parallèle de différentes sections de la suite de tests peut aider à déplacer la construction plus rapidement dans le pipeline. Il faut également veiller à ce que la proportion de chaque type de test ait un sens. Les tests unitaires sont généralement très rapides et ont un minimum de maintenance. En revanche, les tests automatisés de système ou d'acceptation sont souvent complexes et sujets à des ruptures. Pour en tenir compte, il est souvent judicieux de s'appuyer fortement sur les tests unitaires, d'effectuer un nombre assez important de tests d'intégration, puis de revenir sur le nombre de tests ultérieurs plus complexes.

Cohérence dans tout le pipeline de déploiement

Dans la mesure où une mise en œuvre de déploiement ou de distribution continue est supposée tester la validité d'une publication, il est essentiel de maintenir la cohérence à chaque étape du processus: la construction elle-même, les environnements de déploiement et le processus de déploiement lui-même:

  • Le code doit être construit une fois au début du pipeline : Le logiciel résultant doit être stocké et accessible aux processus ultérieurs sans reconstruction. En utilisant exactement le même exécutable dans chaque phase, vous pouvez être certain que vous n'introduisez pas d'incohérences à la suite de différents outils de construction.

  • Les environnements de déploiement doivent être cohérents : un système de gestion de la configuration peut contrôler les différents environnements, et les modifications de l'environnement peuvent passer par le pipeline de déploiement lui-même pour garantir l'exactitude et la cohérence. Des environnements de déploiement propres doivent être configurés à chaque cycle de test pour éviter que les conditions héritées ne compromettent l'intégrité des tests. Les environnements de transfert doivent correspondre le plus possible à l'environnement de production afin de réduire les facteurs inconnus présents lors de la promotion de la version.

  • Des processus cohérents doivent être utilisés pour déployer le nouveau code dans chaque environnement : chaque déploiement doit être automatisé et chaque déploiement doit utiliser les mêmes outils et procédures centralisés. Les déploiements ad hoc doivent être éliminés en faveur du déploiement uniquement avec les outils de pipeline.

Découper le déploiement et le code

Séparer le déploiement du code de sa sortie aux utilisateurs est une partie extrêmement puissante de la livraison et du déploiement continus. Le code peut être déployé en production sans l'activer au départ ou le rendre accessible aux utilisateurs. Ensuite, l'organisation décide quand publier de nouvelles fonctionnalités ou fonctionnalités indépendantes du déploiement.

Cela donne aux organisations une grande flexibilité en séparant les décisions commerciales des processus techniques. Si le code est déjà sur les serveurs, le déploiement n'est plus une partie délicate du processus de publication, ce qui réduit le nombre de personnes et la quantité de travail nécessaire au moment de la publication.

Il existe un certain nombre de techniques qui aident les équipes à déployer le code responsable d'une fonctionnalité sans la livrer. Les indicateurs de fonctionnalité définissent une logique conditionnelle pour vérifier si le code doit être exécuté en fonction de la valeur d'une variable d'environnement. Branch by abstraction permet aux développeurs de remplacer les implémentations en plaçant une couche d'abstraction entre les consommateurs de ressources et les fournisseurs. Une planification minutieuse pour intégrer ces techniques vous donne la possibilité de découpler ces deux processus.

Types de tests

L'intégration continue, la livraison et le déploiement reposent tous fortement sur des tests automatisés pour déterminer l'efficacité et l'exactitude de chaque changement de code. Différents types de tests sont nécessaires tout au long de ces processus pour gagner en confiance dans une solution donnée.

Bien que les catégories ci-dessous ne constituent en aucun cas une liste exhaustive, et bien qu'il existe un désaccord sur la définition exacte de chaque type, ces grandes catégories de tests représentent une variété de façons d'évaluer le code dans différents contextes.

Smoke Testing

Les tests de fumée sont un type particulier de contrôles initiaux conçus pour assurer une fonctionnalité très basique ainsi que certaines hypothèses de base de mise en œuvre et environnementales. Les tests de fumée sont généralement effectués au tout début de chaque cycle de test en tant que vérification de la santé avant d'exécuter une suite de tests plus complète.

L'idée derrière ce type de test est d'aider à attraper de grands drapeaux rouges dans une mise en œuvre et d'attirer l'attention sur des problèmes qui pourraient indiquer que d'autres tests ne sont pas possibles ou ne valent pas la peine. Les tests de fumée ne sont pas très étendus, mais devraient être extrêmement rapides. Si une modification échoue à un test de détection de fumée, c'est un signal précoce que les affirmations de base ont été brisées et que vous ne devriez pas consacrer plus de temps aux tests tant que le problème n'est pas résolu.

Des tests de fumée spécifiques au contexte peuvent être utilisés au début de tout nouveau test de phase pour affirmer que les hypothèses et exigences de base sont satisfaites. Par exemple, les tests de fumée peuvent être utilisés avant les tests d'intégration ou le déploiement sur des serveurs de transfert, mais les conditions à tester varient dans chaque cas.

Tests unitaires

Les tests unitaires sont chargés de tester des éléments individuels du code de manière isolée et très ciblée. La fonctionnalité de chaque fonction et classe est testée individuellement. Toutes les dépendances externes sont remplacées par des implémentations stub ou fictives pour concentrer complètement le test sur le code en question.

Les tests unitaires sont essentiels pour tester l'exactitude des composants de code individuels en termes de cohérence interne et d'exactitude avant de les placer dans des contextes plus complexes. L'étendue limitée des tests et l'élimination des dépendances facilitent la recherche de la cause des défauts. C'est aussi le meilleur moment pour tester une variété d'entrées et de branches de code qui pourraient être difficiles à toucher plus tard. Souvent, après tous les tests de fumée, les tests unitaires sont les premiers tests effectués lorsque des modifications sont apportées.

Les tests unitaires sont généralement exécutés par des développeurs individuels sur leur propre poste de travail avant de soumettre des modifications. Cependant, les serveurs d'intégration continue exécutent presque toujours ces tests comme une sécurité avant de commencer les tests d'intégration.

Test du système

Une fois les tests d'intégration effectués, un autre niveau de test appelé test du système peut commencer. À bien des égards, les tests de système agissent comme une extension des tests d'intégration. L'objectif des tests système est de s'assurer que les groupes de composants fonctionnent correctement comme un ensemble cohérent.

Au lieu de se concentrer sur les interfaces entre les composants, les tests système évaluent généralement la fonctionnalité sortante d'un logiciel complet. Cet ensemble de tests ignore les parties constituantes afin d'évaluer le logiciel composé en tant qu'entité unifiée. En raison de cette distinction, les tests système se concentrent généralement sur les interfaces accessibles aux utilisateurs ou externes.

Test d'acceptation

Les tests d'acceptation sont l'un des derniers types de tests effectués sur les logiciels avant leur livraison. Les tests d'acceptation sont utilisés pour déterminer si un logiciel satisfait à toutes les exigences du point de vue de l'entreprise ou de l'utilisateur. Ces tests sont parfois construits par rapport à la spécification d'origine et testent souvent des interfaces pour les fonctionnalités attendues et pour la facilité d'utilisation.

Les tests d'acceptation sont souvent une phase plus complexe qui peut s'étendre au-delà de la sortie du logiciel. Des tests d'acceptation automatisés peuvent être utilisés pour s'assurer que les exigences technologiques de la conception ont été respectées, mais la vérification manuelle joue aussi généralement un rôle.

Les tests d'acceptation commencent souvent par déployer le nouveau code dans un environnement intermédiaire qui reflète le système de production. À partir de là, les suites de tests automatisées peuvent être exécutées et les utilisateurs internes peuvent accéder au système pour vérifier s'il fonctionne comme ils le souhaitent. Après la diffusion ou l'offre d'un accès bêta aux clients, d'autres tests d'acceptation sont effectués en évaluant le fonctionnement du logiciel avec une utilisation réelle et en recueillant les commentaires des utilisateurs.

Terminologie supplémentaire

Bien que nous ayons discuté de certaines des idées plus générales ci-dessus, il existe de nombreux concepts connexes que vous pourriez rencontrer lorsque vous en apprendrez plus sur l'intégration, la diffusion et le déploiement continus. Définissons quelques autres termes que vous êtes susceptible de voir:

  • Déploiements bleu-vert: Les déploiements bleu-vert est une stratégie pour tester le code dans un environnement de production et pour déployer du code avec un temps d'arrêt minimal. Deux ensembles d'environnements compatibles avec la production sont conservés et le code est déployé sur l'ensemble inactif où les tests peuvent avoir lieu. Lorsqu'il est prêt à être livré, le trafic de production est acheminé vers les serveurs avec le nouveau code, ce qui rend les modifications disponibles instantanément.

  • Branche par abstraction: Branche par abstraction est une méthode d'exécution d'opérations majeures de refactorisation dans un projet actif sans branches de développement à longue durée de vie dans le référentiel de code source, ce que les pratiques d'intégration continue découragent. Une couche d'abstraction est construite et déployée entre les consommateurs et l'implémentation existante afin que la nouvelle implémentation puisse être construite derrière l'abstraction en parallèle.

  • Build (nom) : une build est une version spécifique d'un logiciel créé à partir du code source. Selon la langue, il peut s'agir d'un code compilé ou d'un ensemble cohérent de code interprété.

  • Canary Releases : Les Canary Releases sont une stratégie pour livrer des changements à un sous-ensemble limité d'utilisateurs. L'idée est de s'assurer que tout fonctionne correctement avec les charges de travail de production tout en minimisant l'impact en cas de problèmes.

  • Dark launch: le lancement sombre consiste à déployer du code en production qui reçoit du trafic de production mais n'a aucune incidence sur l'expérience utilisateur. De nouveaux changements sont déployés parallèlement aux implémentations existantes et le même trafic est souvent acheminé vers les deux sites pour les tests. L'ancienne implémentation est toujours connectée à l'interface de l'utilisateur, mais dans les coulisses, le nouveau code peut être évalué en termes de correction en utilisant des requêtes utilisateur réelles dans l'environnement de production.

  • Deployment Pipeline : un pipeline de déploiement est un ensemble de composants qui déplacent le logiciel via des scénarios de test et de déploiement de plus en plus rigoureux afin d'évaluer sa disponibilité pour la publication. Le pipeline se termine généralement par le déploiement automatique en production ou en fournissant l'option de le faire manuellement.

  • Indicateurs d'entités ou bascules d'entités : les indicateurs d'entités sont une technique de déploiement de nouvelles fonctionnalités derrière une logique conditionnelle qui détermine si la fonction doit être exécutée ou non en fonction de la valeur d'une variable d'environnement. Le nouveau code peut être déployé en production sans être activé en configurant le drapeau de manière appropriée. Pour livrer le logiciel, la valeur de la variable d'environnement est modifiée, provoquant l'activation du nouveau chemin de code. Les indicateurs de fonctionnalité contiennent souvent une logique qui permet à des sous-ensembles d'utilisateurs d'accéder à la nouvelle fonctionnalité, créant ainsi un mécanisme permettant de déployer progressivement le nouveau code.

  • Promouvoir : Dans le contexte de processus continus, la promotion signifie le passage d'un logiciel à l'étape suivante de test.

  • Soak Test: Le soak test consiste à tester un logiciel sous une production importante ou une charge similaire à la production pendant une période de temps prolongée.

Conclusion

Dans ce modeste ticket, nous avons introduit l'intégration continue, la livraison continue et le déploiement continu et nous avons discuté de la façon dont ils peuvent être utilisés pour créer et distribuer des logiciels bien testés en toute sécurité et rapidement. Ces processus s'appuient sur une automatisation poussée et encouragent le partage de code constant pour corriger les défauts plus tôt. Bien que les techniques, les processus et les outils nécessaires pour mettre en œuvre ces solutions représentent un défi important, les avantages d'un système bien conçu et correctement utilisé peuvent être énormes. Pour trouver la solution CI / CD qui convient le mieux à votre projet, dans un prochain article nous ferons la comparaisons de différents outils CI / CD (Jenkins, Gitlab CI, Buildbot, Drone et Concourse).

A propos de SUPINFO | Contacts & adresses | Enseigner à SUPINFO | Presse | Conditions d'utilisation & Copyright | Respect de la vie privée | Investir
Logo de la société Cisco, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société IBM, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sun-Oracle, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Apple, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sybase, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Novell, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Intel, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Accenture, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société SAP, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Prometric, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Toeic, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo du IT Academy Program par Microsoft, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management

SUPINFO International University
Ecole d'Informatique - IT School
École Supérieure d'Informatique de Paris, leader en France
La Grande Ecole de l'informatique, du numérique et du management
Fondée en 1965, reconnue par l'État. Titre Bac+5 certifié au niveau I.
SUPINFO International University is globally operated by EDUCINVEST Belgium - Avenue Louise, 534 - 1050 Brussels