Fermez

Notions fondamentales du pipeline de livraison continue

Découvrez comment les builds, les tests et les déploiements automatisés sont reliés entre eux pour former un workflow de livraison unique.

Qu'est-ce qu'un pipeline de livraison continue ?

How does a pipeline relate to continuous delivery (CD)? As the name suggests, a continuous delivery pipeline is an implementation of the continuous paradigm, where automated builds, tests and deployments are orchestrated as one release workflow. Put more plainly, a CD pipeline is a set of steps your code changes will go through to make their way to production.

A CD pipeline delivers, as per business needs, quality products frequently and predictably from test to staging to production in an automated fashion.

For starters, let’s focus on the three concepts: quality, frequently, and predictably.

We emphasize on quality to underscore that it’s not traded off for speed. Business doesn’t want us to build a pipeline that can shoot faulty code to production at high speed. We will go through the principles of “Shift Left” and “DevSecOps”, and discuss how we can move quality and security upstream in the SDLC (software development life cycle). This will put to rest any concerns regarding continuous delivery pipelines posing risk to businesses.

Frequently indicates that pipelines execute at any time to release features, since they are programmed to trigger with commits to the codebase. Once the pipeline MVP (minimum viable product) is in place, it can execute as many times as it needs to with periodic maintenance cost. This automated approach scales without burning out the team. This also allows teams to make small incremental improvements to their products without the fear of a major catastrophe in production.

Cliche as it may sound, the nation of “to err is human” still holds true. Teams brace for impact during manual releases since those processes are brittle. Predictably implies that releases are deterministic in nature when done via continuous delivery pipelines. Since pipelines are programmable infrastructure, teams can expect the desired behavior every time. Accidents can happen, of course, since no software is bug-free. However, pipelines are exponentially better than manual error-prone release processes, since unlike humans, pipelines don’t falter under aggressive deadlines.  

Les pipelines sont dotés de portes logicielles qui autorisent ou bloquent automatiquement le passage des artefacts versionnés. Si le protocole de livraison n'est pas respecté, les portes logicielles restent fermées, et le pipeline s'annule. Des alertes sont générées et des notifications sont envoyées à une liste de distribution comprenant les membres de l'équipe susceptibles d'être à l'origine du problème sur le pipeline.

C'est ainsi que fonctionne un pipeline de livraison continue : un commit, ou un petit lot incrémentiel de commits, est mis en production à chaque fois que le pipeline s'exécute correctement. À la fin, les équipes livrent des fonctionnalités (et en bout de ligne, des produits) dans un contexte sécurisé et vérifiable.

Continuous delivery pipeline articles

[CONTINUED]

Les différentes phases d'un pipeline de livraison continue

L'architecture du produit qui parcourt le pipeline est un facteur clé qui détermine l'anatomie du pipeline de livraison continue. Une architecture de produit à couplage fort génère un modèle graphique complexe de pipelines, dans lequel de multiples pipelines s'enchevêtrent avant que le produit ne soit finalement mis en production.

L'architecture du produit affecte également les différentes phases du pipeline et les artefacts produits dans chaque phase. Abordons à présent les quatre phases courantes de livraison continue :

Even if you foresee more than four phases or less than four in your organization, the concepts outlined below still apply.

L'idée selon laquelle ces phases se manifestent matériellement dans votre pipeline est une méprise courante. En vérité, ce n'est pas le cas. Il s'agit de phases logiques qui peuvent être associées à des étapes importantes dans différents contextes (test, staging et production, par exemple). Par exemple, les composants et les sous-systèmes peuvent être développés, testés et déployés dans l'environnement de test. Les sous-systèmes ou les systèmes peuvent être assemblés, testés et déployés dans l'environnement de staging. Les sous-systèmes ou les systèmes peuvent être mis en production dans le cadre de la phase de production.

Le coût associé aux défauts est faible lorsque ces derniers sont détectés dans l'environnement de test, il est modéré lorsque les défauts sont détectés dans l'environnement de staging, et il est élevé en production. L'expression « Shift Left » signifie que les validations sont obtenues plus tôt dans le pipeline. De nos jours, la porte permettant au produit de passer de la phase de test à la phase de staging intègre des techniques défensives bien plus efficaces ; ainsi, la phase de staging ne ressemble plus à une scène de crime !

À l'origine, le service de sécurité informatique intervenait à la toute fin du cycle de vie de développement logiciel (SDLC) et rejetait les versions susceptibles de constituer une menace pour l'entreprise en termes de cybersécurité. Même si ses intentions étaient nobles, son action était source de frustration et de retards. Le principe « DevSecOps » préconise d'intégrer la sécurité dans les produits dès la phase de conception, au lieu d'envoyer pour évaluation un produit fini susceptible de présenter un danger.

Examinons de plus près la façon dont les concepts de « Shift Left » et de « DevSecOps » peuvent être traités dans le cadre d'un workflow de livraison continue. Dans les sections suivantes, nous aborderons en détail chacune des phases.

CD Component phase

The pipeline first builds components - the smallest distributable and testable units of the product. For example, a library built by the pipeline can be termed a component. A component can be certified, among other things, by code reviews, unit tests, and static code analyzers.

Les revues de code sont importantes pour que les équipes aient une compréhension commune des fonctionnalités, des tests et de l'infrastructure nécessaires à la mise en service du produit. Une deuxième paire d'yeux peut souvent faire des miracles. Au fil des ans, il se peut que nous nous soyons immunisés contre le mauvais code d'une manière telle que nous ne croyons plus qu'il est mauvais. De nouvelles perspectives peuvent nous obliger à réexaminer ces faiblesses et à les refactoriser généreusement au besoin.

Les tests unitaires sont presque toujours la première série de tests logiciels que nous exécutons sur notre code. Ils ne touchent ni la base de données ni le réseau. La couverture de code est le pourcentage de code qui a été touché par les tests unitaires. Il existe de nombreuses façons de mesurer la couverture, comme la couverture de ligne, la couverture de classe, la couverture de méthode, etc.

Bien qu'il soit formidable d'avoir une bonne couverture de code pour faciliter le refactoring, il est préjudiciable d'imposer des objectifs de couverture élevés. Contrairement à l'intuition, certaines équipes ayant une couverture de code élevée ont plus de pannes de production que les équipes ayant une couverture de code plus faible. Gardez également à l'esprit qu'il est facile de jouer avec les données liées à la couverture. Lorsqu'ils sont soumis à une forte pression, en particulier pendant les évaluations de performances, les développeurs peuvent recourir à des pratiques déloyales pour accroître la couverture de code. Je ne donnerai pas tous les détails ici !

Static code analysis detects problems in code without executing it. This is an inexpensive way to detect issues. Like unit tests, these tests run on source code and have low run-time. Static analyzers detect potential memory leaks, along with code quality indicators like cyclomatic complexity and code duplication. During this phase, SAST (static analysis security testing) is a proven way to discover security vulnerabilities.

Définissez les métriques qui contrôlent vos portes logicielles et influencent la promotion du code de la phase Composant à la phase Sous-système.

Phase Sous-système CD

Les composants à couplage lâche constituent des sous-systèmes ; les plus petites unités déployables et exploitables. Par exemple, un serveur est un sous-système. Un microservice fonctionnant dans un conteneur est également un exemple de sous-système. Contrairement aux composants, les sous-systèmes peuvent être mis en place et validés en les comparant à des cas d'usage client.

Tout comme une interface utilisateur Node.js et une couche API Java sont des sous-systèmes, les bases de données sont aussi des sous-systèmes. Dans certaines organisations, les systèmes de gestion de bases de données relationnelles (SGBDR) sont gérés manuellement, même si une nouvelle génération d'outils a fait surface et automatise la gestion des changements de bases de données et assure la livraison continue des bases de données. Les pipelines CD impliquant des bases de données NoSQL sont plus faciles à implémenter que les SGBDR.

Subsystems can be deployed and certified by functional, performance, and security tests. Let’s study how each of these test types validate the product.

Les tests fonctionnels incluent tous les cas d'usage client qui impliquent l'internationalisation (I18N), la localisation (L10N), la qualité des données, l'accessibilité, les scénarios négatifs, etc. Ces tests permettent de s'assurer que votre produit fonctionne conformément aux attentes du client, qu'il respecte l'inclusion et qu'il sert le marché pour lequel il a été conçu.

Déterminez vos benchmarks de performance avec vos product owners. Intégrez vos tests de performance au pipeline et utilisez les benchmarks pour adopter ou rejeter les pipelines. Un mythe répandu veut que les tests de performance n'ont pas besoin d'être intégrés aux pipelines de livraison continue, ce qui brise toutefois le paradigme de la continuité.

Les lignes de sécurité de grandes organisations ont été récemment percées, et les menaces contre la cybersécurité sont à leur plus haut niveau. Nous devons nous assurer qu'il n'y a aucune faille de sécurité dans nos produits, que ce soit dans le code que nous programmons ou dans les bibliothèques tierces que nous importons dans notre code. En réalité, des violations majeures ont été découvertes dans les logiciels open source (OSS), et nous devons utiliser des outils et des techniques qui signalent ces erreurs et forcent le pipeline à s'annuler. Le test de la sécurité par analyse dynamique (DAST) est un moyen éprouvé de découvrir les failles de sécurité.

Le schéma suivant illustre le worklow décrit dans les phases Composant et Sous-système. Exécutez des étapes indépendantes en parallèle pour optimiser le temps total d'exécution du pipeline et obtenir un feedback rapide.

A) Certifying components and/or subsystems in the test environment

Phase Système CD

Once subsystems meet functional, performance, and security expectations, the pipeline could be taught to assemble a system from loosely coupled subsystems in cases where the entire system has to be released as a whole. What that means is that the fastest team can go at the speed of the slowest team. Reminds me of the old saying, “A chain is only as strong as its weakest link”.

We recommend against this composition anti-pattern where subsystems are composed into a system to be released as a whole. This anti-pattern ties all the subsystems at their hips for success. If you invest in independently deployable artifacts, you will be able to avoid this anti-pattern.

Where systems need to be validated as a whole, they can be certified by integration, performance, and security tests. Unlike subsystem phase, do not use mocks or stubs during testing in this phase. Also, focus on testing interfaces and network more than anything else.

Si vous devez assembler vos sous-systèmes par composition, le schéma suivant résume le workflow de la phase Système. Même si vous pouvez faire passer vos sous-systèmes en production, l'illustration suivante vous aide à établir les portes logicielles nécessaires pour promouvoir le code de cette phase à la suivante.

The pipeline can automatically file change requests (CR) to leave an audit trail. Most organizations use this workflow for standard changes, which means, planned releases. This workflow should also be used for emergency changes, or unplanned releases, although some teams tend to cut corners. Note how the change request (CR) is closed automatically by the CD pipeline when errors force it to abort. This prevents CRs from being abandoned in the middle of the pipeline workflow.

Le schéma suivant illustre le worklow décrit dans la phase Système CD. Notez que certaines étapes peuvent nécessiter une intervention humaine et que ces étapes manuelles peuvent être exécutées dans le cadre de portes manuelles dans le pipeline. Lorsqu'elle est entièrement cartographiée, la visualisation du pipeline ressemble étroitement à la cartographie de la chaîne de valeur de vos livraisons de produits !

B) Certification des sous-systèmes et/ou du système dans l'environnement de staging

Une fois le système assemblé certifié, ne modifiez pas l'assembly et mettez-le en production.

Phase Production CD

Que les sous-systèmes puissent être déployés indépendamment ou qu'ils doivent être assemblés dans un système, ces artefacts versionnés sont déployés en production dans le cadre de cette phase finale.

Zero downtime deployment (ZDD) est un outil indispensable pour éviter les temps d'arrêt pour les clients. Il doit être appliqué tout au long du processus, du test à la production en passant par le staging. Le Blue-Green Deployment est une technique ZDD populaire où les nouveaux bits sont déployés sur un petit échantillon représentatif de la population (appelé « green »), tandis que la majorité des utilisateurs ne sont pas au courant du « blue » qui contient les anciens bits. Le moment venu, tout le monde repasse au « blue », et très peu de clients, voire aucun, sont affectés. Si tout à l'air correct sur « green », faites lentement migrer tout le monde de « blue » vers « green ».

Certaines organisations exigent une ou deux portes manuelles avant que le pipeline ne soit mis en production. Dans certains cas, les portes manuelles sont légitimes : par exemple, une entreprise peut souhaiter cibler un certain profil géographique ou démographique de la population et recueillir les données avant de les diffuser dans le monde.

Je constate cependant que certaines organisations abusent des portes manuelles. Elles exigent que les équipes obtiennent une approbation manuelle lors d'une réunion du comité d'approbation des changements (CAB). La raison est le plus souvent une mauvaise interprétation de la séparation des tâches ou de la séparation des problèmes, et un service qui passe la main à un autre pour obtenir l'approbation d'aller de l'avant. J'ai également vu certains approbateurs du CAB faire preuve d'une compréhension technique superficielle des changements en production, ce qui rend le processus d'approbation manuel lent et fastidieux.

This is a good segway to call out the difference between continuous delivery and continuous deployment. Continuous delivery allows manual gates whereas continuous deployment doesn’t. While both are referred to as CD, continuous deployment requires more discipline and rigor since there is no human intervention in the pipeline.

Il y a une différence entre déplacer les bits et les activer. Lors de la production, exécutez des smoke tests, qui sont un sous-ensemble des suites de tests d'intégration, de performance et de sécurité. Lorsque les résultats des smoke tests sont satisfaisants, activez les bits et le produit est mis à la disposition de nos clients !

The following diagram illustrates the steps carried out by the team in this final phase of continuous delivery.

C) Certifying subsystems and/or system in the production environment

La livraison continue est la nouvelle norme

Pour réussir une livraison continue ou un déploiement continu, il est essentiel de bien effectuer l'intégration continue ainsi que les tests continus. Avec une base solide, vous gagnerez sur les trois fronts : qualité, fréquence et prévisibilité.

A continuous delivery pipeline helps your ideas become products through a series of sustainable experiments. If you discover your idea isn’t as good as you thought it was, you can quickly turn around with a better idea. Additionally, pipelines reduce the MTTR (mean time to resolve) production issues, thus reducing downtime for your customers. With continuous delivery, you end up with productive teams and satisfied customers, and who doesn’t want that?

Learn more in our Continuous Delivery tutorial.

Juni Mukherjee
Juni Mukherjee

Juni is a thought citizen in the DevSecOps space and has made deep investments in the field of Continuous Delivery. She has helped organizations build Continuous Delivery Pipelines, and would love to solve the problems that plague our industry today. She has authored a couple of books.