Difference between revisions of "Continuous Deliver"

From air
Jump to navigation Jump to search
Line 1: Line 1:
 
Avant de parler du continous delivery, il est important dans un premier temps de rappeler l’intégration continue :
 
Avant de parler du continous delivery, il est important dans un premier temps de rappeler l’intégration continue :
−  
−
== Le continuous delivery : Comment ? ==
  
−  
−
===Etat des lieux et définition du pipeline de votre projet===
  
−  
−
Une première étape lorsque vous voulez mettre en place le Continuous Delivery dans votre projet/entreprise est de faire un état des lieux de votre Pipeline (constitué par toutes les étapes à partir du besoin jusqu’à la mise en production) et d’estimer le temps passé lors de chaque étape. Il n’est pas question de faire un bing-bang : il faut faire évoluer étape par étape adressant les goulots d’étranglement les uns après les autres et savoir s’adapter au contexte de votre projet/entreprise.
  
−  
−  
−
[[File:Pipeline.png]]
  
−  
−
Une fois que vous avez identifié les différentes briques de votre Pipeline, vous pourrez identifier quelles sont les étapes qui prennent le plus de temps, celles qui sont les plus douloureuses ou celles qui sont le plus obscures. Posez vous la question de ce qui est possible d’améliorer. Pour cela, identifiez les pratiques automatisées et les pratiques manuelles ainsi que ce qui empêche l’automatisation. Quelles sont les étapes qui vous demande le plus de temps. Quelles sont les étapes qui sont entièrement sous votre contrôle et celles qui sont dépendantes de décisions ou d’actions externes à votre projet.
  
−  
−
De cet état des lieux, vous pourrez investiguer sur les causes de vos maux afin de les adresser. Vous vous rendrez probablement compte que certaines étapes sont très consommatrices de temps (en charge ou en délais) sans forcément donner un retour sur investissement.
  
−  
−  
−
===Automate all the things – Il faut tout automatiser===
  
−
Si vous vous posez la question de savoir qu’elle démarche appliquer la réponse est simple :
  
−  
−
[[File:Automation.png]]
  
−  
−
En effet, le continuous delivery prends tout son sens lorsque toutes les étapes du pipeline sont entièrement automatisées. Ainsi, lorsque toutes les étapes sont automatisées, le temps entre la première étape et la dernière étape peut être connu et garanti ( on n’est pas obligé d’attendre qu’une personne bien précise soit disponible pour pouvoir faire la livraison, chaque étape est rejouable à loisir et son temps d’exécution est mesuré et historisé).
  
−
Il faut par ailleurs garder à l’esprit que, bien que toutes les étapes soient automatisées (c’est-à-dire qu’aucune intervention manuelle n’est nécessaire pour réaliser une étape du pipeline), il peut arriver que le déclenchement d’une ou plusieurs étapes soit faite manuellement du fait de contraintes fortes externe au projet ( validation par une entité externe à l’entreprise par exemple). Même si c’est le genre de cas qu’on cherchera particulièrement à éviter.
  
−  
−
Les commandements de l’automatisation
  
−
Tu automatiseras tout, absolument tout :
  
−  
−
*Tu n’installeras pas manuellement tes dépendances ;
  
−
*Tu automatiseras ta build ;
  
−
*Tu automatiseras tes tests ;
  
−
*Tu ne configureras pas à la main;
  
−
*Tu ne créeras plus de machine à la main ;
  
−
*Tu n’interviendras pas pour livrer ;
  
−
*Des métriques tu auras, tes machines tu monitoreras ;
  
−  
−
Vous l’aurez compris, pour la mise en place du Continuous Delivery, il faut que tout soit automatisé et répétable. Ainsi, il faut adresser l’environnement de production (sa construction) dès le départ. De fait, dès la mise en place de l’intégration continue, il faut faire en sorte que l’environnement dans lequel se font les différents tests (unitaires, intégration, performance,…) soient fait dans un environnement identique, sinon le plus semblable possible à l’environnement de production, de façon à se rendre compte le plus tôt possible des problèmes potentiels liés à l’environnement.
  
−  
−
Un pattern répandu qui peut être mis en place est l’Infrastructure As Code où l’environnement est mis en place grâce à des scripts de configuration. Pour cela on utilisera des outils permettant de simplifier ce travail (Puppet, Chef, Vagrant, Docker, …).
  
−  
−
Donc plus rien ne doit rester une tâche manuelle, et tous les artefacts permettant la mise en production doivent ainsi être archivés dans le contrôleur de code source : les scripts de mise à jour de la base de donnée, la configuration des environnements, les scripts de déploiement, …
  
−
Le Continuous Delivery, c’est aussi un rythme
  
   
 
== Quel rythme pour le continuous delivery ? Quel changement implique-t-il ? ==
  
== Quel rythme pour le continuous delivery ? Quel changement implique-t-il ? ==

Revision as of 18:28, 4 February 2015

Avant de parler du continous delivery, il est important dans un premier temps de rappeler l’intégration continue :

Quel rythme pour le continuous delivery ? Quel changement implique-t-il ?

Une des interrogations des plus intéressantes qui nous pousse à avoir cette démarche, est de nous interroger, sur la valeur à donner à des fonctionnalités développées mais non encore mise en production. La réponse, brutale et non moins réalise, est : aucune.

Un des travers que nous pouvons rencontrer encore maintenant sur les projets, est de voir les fonctionnalités s’accumuler.

Toute cette perte de temps est causée parfois par le focus mis sur le développement de nouvelles fonctionnalités sans se soucier de leur livraison… Cette perte de temps est un travers fréquent lors de l’utilisation de la méthode Scrum où la vélocité est calculé par la capacité de l’équipe à produire du code et non pas de la valeur.

Nous pourrions proposer un nouveau principe : rendre votre produit déployable plutôt que livrer de nouvelle fonctionnalités puisque toute fonctionnalité non livrée n’amène pas de valeur.

Voir aussi

Liens externes

Retrieved from "https://air.imag.fr/index.php?title=Continuous_Deliver&oldid=20906"