Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Passez au DevOps
  3. Les principes du CI/CD
Extrait - Passez au DevOps Votre nouvelle façon de travailler
Extraits du livre
Passez au DevOps Votre nouvelle façon de travailler
1 avis
Revenir à la page d'achat du livre

Les principes du CI/CD

Le cycle de vie des applications

1. Comment définir le cycle de vie ?

Nous ne parlons pas ici du cycle commercial mais du cycle opérationnel. Les deux peuvent cependant se rejoindre.

Le cycle commercial ressemble à une courbe en cloche. Elle décrit des phases commerciales assez simples :

images/07EI01.png

C’est une vision du produit pour le moins… "humaine" ! Y aurait-il ici une superposition inconsciente de l’image de notre propre destinée ? Cette représentation est pourtant celle qui fait figure de référence dans le monde du marketing.

La phase de conception et de développement du produit est positionnée avant cette courbe. Pour reprendre le fil de notre métaphore, c’est un peu comme si l’activité de développement du produit correspondait à la grossesse pour un être humain, jusqu’au déploiement qui serait le jour de l’accouchement.

images/07EI02.png

Évidemment, cela ne correspond pas à la vision Lean du cycle de vie du produit tel que nous l’avons définie tout au long des chapitres précédents, à savoir un moyen d’apporter de la valeur en continu auprès des clients. Est-ce que cela remet en cause l’idée d’un début et d’une fin pour le produit ? Assurément non. Une innovation, un changement d’usage, un contexte différent sont autant de facteurs qui finissent par rendre un produit obsolète. On pourrait aussi dire qu’à un moment le coût d’évolution d’un produit existant ne compense plus le coût du développement d’un produit de rupture, ce qui mène à sa fin de vie.

D’un point de vue Lean et agile, durant le cycle de vie du produit, l’ingénierie et la commercialisation sont intriqués beaucoup plus...

Intégrer et déployer en continu

1. Les objectifs

Le chapitre La configuration : fondation du DevOps met en évidence l’intérêt d’intégrer en continu. Une intégration fréquente diminue les coûts d’intégration et permet d’anticiper largement les problèmes liés au travail en équipe. En étant informé très rapidement de ce que le reste de l’équipe fait, le développeur peut rapidement ajuster son code et introduire le travail de l’autre dans sa propre réalisation. Cela permet de ne pas avoir à traiter des problèmes de conflits entre développeurs.

Le déploiement continu et la livraison continue (la différence sera expliquée plus loin), sont le prolongement de l’intégration continue et permettent d’aller jusqu’au bout du paradigme agile en proposant au plus tôt le déploiement de ce qui est développé.

Nous retrouvons donc des bénéfices en ligne avec ce qui est attendu des pratiques Lean :

  • Une équipe centrée sur des activités strictement nécessaires à la réalisation du produit plutôt que sur des tâches administratives de coordination.

  • L’amélioration du Time To Market (temps entre la conception et la mise en marché) en mettant à disposition des utilisateurs un flux continu de nouvelles fonctionnalités.

  • Une plus grande stabilité des versions : magie des petits lots et des itérations, plus le déploiement se fait sur de petits périmètres, moins il est risqué. L’automatisation de toute la chaîne jusqu’au déploiement permet de traiter la majorité des problèmes avant la mise en production.

  • Une plus grande qualité : chaque...

Les stratégies de déploiement

La livraison continue et le déploiement continu offrent de nouvelles stratégies de déploiement. Ces stratégies ont pour objectif principal d’améliorer drastiquement le time to market et de construire un flux continu de valeur.

1. Initier les premiers déploiements

a. Une vieille histoire…

Le premier déploiement d’une application est un moment spécial et très anxiogène pour une équipe non DevOps. Déployer pour la première fois signifie alors mettre à disposition de l’utilisateur le résultat de mois, voire d’années de travail. Tous les développements accumulés au cours de cette longue période n’ont fait qu’empiler des choix et des décisions qui ont à chaque fois multiplié la complexité de l’application. Quelle angoisse ! Se posent alors de multiples questions :

  • Tous les composants sont-ils bien intégrés ?

  • La configuration est-elle bonne ?

  • La base est-elle bien indexée ?

  • Tous les flux réseaux sont-ils bien ouverts ?

  • La plateforme est-elle bien dimensionnée ?

  • ...

Dans ce cas de figure, un document d’architecture complet a sans doute été produit en tout début de projet, sur les recommandations d’un éditeur de solutions ou de l’équipe de développement qui, si cela s’est bien passé, a demandé à l’équipe de production de lui fournir les piles techniques homologuées par l’entreprise. L’équipe d’architectes système a alors formulé des hypothèses structurantes permettant de définir le dimensionnement cible de l’application, en fonction évidemment du taux d’utilisation - en d’autres...