Close

Livraison continue

La livraison continue (CD) consiste à utiliser l'automatisation pour livrer des logiciels par petites itérations

Qu'est-ce que la livraison continue ?


La livraison continue est une approche dans laquelle les équipes mettent automatiquement en production le code source de produits de qualité de façon fréquente et prévisible.

Certaines organisations livrent des produits manuellement, en les transmettant d'une équipe à une autre. Voir le schéma ci-dessous. Généralement, les développeurs sont à l'extrémité gauche de ce spectre et les équipes opérationnelles, à l'extrémité réceptrice. Cette situation engendre des retards à chaque transfert, ce qui suscite frustration chez les équipes et insatisfaction chez les clients. Le produit finit par être mis en ligne par le biais d'un processus complexe et sujet aux erreurs, ce qui retarde la création de revenus.

Figure 1 : Livraison manuelle de produits aux clients
Étapes de livraison manuelle : développement, assurance qualité, outils, infrastructure, plateforme, livraison, InfoSec

Observez maintenant le pipeline de livraison continue ci-dessous. Il illustre comment les développeurs écrivent du code sur leurs ordinateurs portables et commitent les changements dans un dépôt de code source comme Bitbucket. Par code, nous entendons le système en cours de test, les tests et l'infrastructure utilisée pour déployer et administrer le système. Bitbucket Pipelines peut livrer le produit de l'environnement de test vers ceux de staging et de production, tout en aidant les clients à tirer parti de ces nouvelles fonctionnalités.

Figure 2 : Pipeline de livraison continue réalisant des livraisons automatisées
Étapes du pipeline de livraison continue : développeur, ordinateur portable, Bitbucket, pipelines Bitbucket, clients

Comment fonctionne la livraison continue ?


Un pipeline de livraison continue pourrait avoir une « porte » manuelle juste avant l'environnement de production. Une telle porte requiert une intervention humaine, et certains scénarios dans votre organisation pourraient nécessiter des portes manuelles dans les pipelines. Certaines portes manuelles peuvent être remises en question, alors que d'autres peuvent être légitimes. Un scénario légitime permet à l'équipe business de décider de livrer à la dernière minute. L'équipe d'ingénierie conserve une version livrable du produit après chaque print, et l'équipe business prend la décision finale de livrer le produit à tous les clients (ou à un échantillon de la population, voire à des personnes résidant dans une certaine zone géographique).

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. Le pipeline génère d'abord les composants (les plus petites unités distribuables et testables du produit). Par exemple, une bibliothèque conçue par le pipeline peut être qualifiée de composant. C'est la phase Composant.

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. C'est la phase Sous-système. Contrairement aux composants, les sous-systèmes peuvent être mis en place et testés.

Par conséquent, il est possible d'apprendre au pipeline à assembler un système à partir de sous-systèmes à couplage lâche quand tout le système doit être livré en un bloc. C'est la phase Système.

Nous déconseillons cette composition lorsque les sous-systèmes sont assemblés en un système. Découvrez une illustration de ceci dans la Figure 3.

Figure 3 : Sous-systèmes assemblés en un seul système
Diagramme de sous-système

Cette approche du tout ou rien force le sous-système le plus rapide à s'adapter à la vitesse de celui le plus lent. Nous utilisons le cliché « Une chaîne est aussi solide que le plus faible de ses maillons » pour avertir les équipes qui tombent dans le piège de ce modèle d'architecture.

Une fois validé, le système assemblé est alors promu en production sans autre modification. Il entre alors dans la phase finale appelée Production.

Remarque : ces phases sont plus logiques que physiques. Elles sont uniquement créées pour répartir un grand problème en plus petits sous-problèmes. Vous pouvez avoir plus ou moins de phases, en fonction de votre architecture et de vos exigences.

Sans la qualité, la vitesse n'a aucun intérêt pour nos clients. Les tests continus constituent une technique dans laquelle des tests automatisés sont intégrés au pipeline de livraison de logiciels et valident chaque changement entrant. Les tests s'exécutent durant chaque phase du pipeline pour valider les artefacts produits dans cette phase. Les tests unitaires et l'analyse de code statique valident les composants dans la phase Composant du pipeline. Les tests fonctionnels, de performance et de sécurité valident les sous-systèmes dans la phase Sous-système. Les tests d'intégration, de performance et de sécurité valident les systèmes dans la phase Système. Enfin, les smoke tests valident le produit dans la phase Production.

Illustration de revue de code

Tests automatisés intégrés au pipeline

Une architecture de produit monolithique ou un « mammouth » peut entraîner une avalanche de tests. Nous vous recommandons d'investir dans des microservices tels que des artefacts déployables indépendamment qui peuvent circuler dans les pipelines sans nécessiter d'environnement hautement intégré pour la certification. De même, les artefacts déployables indépendamment permettent aux équipes plus rapides de ne pas être enlisées par les équipes plus lentes.

Valeur de la livraison continue


Le pipeline de livraison de logiciels est un produit à part entière et constitue une priorité pour les entreprises. Sinon, nous n'enverrions pas nos produits générateurs de revenus à travers celui-ci. La livraison continue apporte une valeur ajoutée de trois manières différentes. Elle améliore la vélocité, la productivité et la durabilité des équipes de développement logiciel.

Illustration de navette spatiale

Vélocité

La vélocité signifie vitesse responsable, et non suicidaire. Les pipelines sont conçus pour livrer des produits de qualité aux clients. Sauf si les équipes sont disciplinées, les pipelines peuvent entraîner la mise en production encore plus rapide de code défaillant. Les pipelines de distribution de logiciels automatisés aident les organisations à mieux répondre à l'évolution du marché.

Illustration de code dans le pipeline

Productivité

Un pic dans la production se produit lorsque des tâches pénibles, comme la soumission d'une demande de changement pour chaque changement en production, peuvent être effectuées par des pipelines plutôt que par des humains. Ainsi, les équipes Scrum peuvent se concentrer sur les produits qui fascinent le monde, et non épuiser leur énergie sur des questions de logistique. Les membres de l'équipe n'en sont que plus heureux, plus impliqués et plus fidèles.

Illustration de décision

Durabilité

La durabilité est essentielle pour toutes les entreprises, pas seulement celles spécialisées dans les technologies. La formule selon laquelle « les logiciels sont en train de conquérir le monde » n'est plus vraie. Les logiciels ont déjà conquis le monde ! À la fin de la journée, chaque entreprise, qu'elle soit spécialisée dans les soins de santé, la finance, la vente au détail ou un autre domaine, applique des technologies pour se différencier et damer le pion à ses concurrents. L'automatisation contribue à réduire/éliminer les tâches manuelles sujettes aux erreurs et répétitives. Elles positionnent ainsi l'entreprise pour lui permettre de mieux innover et de répondre plus rapidement aux besoins de ses clients.

Qui doit effectuer la livraison continue et quand ?


Quand le moment est-il choisi pour adopter la livraison continue ? De préférence, hier.
Les équipes ont besoin d'un seul backlog hiérarchisé :

  1. qui fait la part belle à la livraison continue, plutôt que de la reléguer en arrière-plan ;
  2. dans lequel les critères d'acceptation des users stories mentionnent explicitement des approches de livraison automatisées et non manuelles ;
  3. la définition de « Terminé » du sprint empêche les équipes de terminer des sprints lorsque le produit est livré manuellement.

La livraison continue est la bonne technique à adopter. Occasionnellement, elle requiert des champions pour amorcer la transformation. Lorsqu'ils sont bien conçus, les pipelines de livraison continue sont rentables.

Alors, qui est impliqué ?

Certaines organisations ont chargé des personnes inexpérimentées de concevoir et d'implémenter des pipelines de livraison continue. Elles ont appris à leurs dépens les profondes subtilités impliquées. La nomination de membres de l'équipe juniors véhicule le mauvais message aux équipes et implique que la livraison continue n'est pas prioritaire. Nous vous recommandons vivement de nommer pour responsable un architecte senior qui apprécie sincèrement la technologie et le business.

Au-delà de la livraison continue


Où que vous en soyez dans votre parcours (intégration, test, livraison, déploiement, analyse, etc.), l'amélioration continue ne constitue ni une checklist, ni une destination. Elle est au cœur de votre démarche.

Tôt ou tard, chaque membre de l'organisation recevra un appel lorsque des pipelines de livraison continue sont en cours de développement. Et ce, quelle que soit l'équipe à laquelle il appartient (direction, ingénierie, gestion produit, gouvernance, risque, conformité, InfoSec, opérations, juridique, ou autre). Les pipelines attaquent les silos et éliminent les cloisons. Chacun d'entre nous prend part à cette transformation d'une manière ou d'une autre, et la continuité est la nouvelle norme !

Lancez-vous avec la CI/CD

Pour pratiquer la CI/CD, vous pouvez utiliser des outils qui automatisent le développement, le déploiement et les tests. Des outils spécifiques permettent l'intégration, d'autres favorisent le développement et le déploiement, tandis que d'autres proposent des tests.

Atlassian propose une solution Open DevOps qui fournit des processus DevOps de bout en bout, notamment de CI/CD. Les équipes peuvent utiliser de nombreux outils de CI/CD, notamment Bitbucket Pipelines, un service de CI/CD intégré à Bitbucket qui vous permet de développer, tester et même déployer automatiquement votre code en fonction d'un fichier de configuration dans votre dépôt. Open DevOps s'intègre également à d'autres outils de CI/CD, notamment Harness, GitLab, JFrog, Codefresh et CircleCI.

Voici un aperçu plus détaillé de nos intégrations Open DevOps. N'oubliez pas de consultez nos Tutoriels sur la CI/CD dans DevOps.

Illustration de la livraison continue