Les enjeux du Déploiement Continu

Le déploiement continu bouleverse le processus habituel de mise en production. Entre réduction du temps de cycle, livraisons fréquentes et automatisation, quels sont réellement les enjeux du Continuous Deployement ?

déploiement continu

Déployer en continu signifie qu’à intervalle régulier, le code est compilé, testé assemblé et parfois déployé sur un environnement d’intégration, le but étant de réduire le temps écoulé entre l’écriture d’une ligne de code et l’utilisation réelle de ce code par des utilisateurs finaux.  On parle aussi souvent de « Continuous delivery » : C’est la même chose que le continous déployement sauf qu’à la fin du processus, le code est livré à l’équipe suivante. Attention, le continuous deployement n’est pas réservé qu’aux Start Up, pour exemple : Etsy fait 25 déploiements par jours et ils sont plus de 200 ingénieurs sachant qu’en 2012 il y a 196 personnes différentes qui ont déployé en production. Chez la Direction Service and Cloud on est à 4 mises en production applicatives par jour depuis 2 ans.

Quelques records des champions du Continous Deployment :

– Amazon déploie une fois toutes les 10 secondes sur environ 2000 machines.

– Facebook fait environ 2 déploiements par jour.

Pourquoi faut-il se forcer à faire déployer plusieurs fois par jour ?

Déployer en continu c’est pas déjà ce qu’on fait avec les méthodes Agiles ? Non pas tout à fait nous explique Benoit Lafontaine. En effet souvent on déploie toutes les 5, 6, 10 itérations .Le problème est que lorsque l’on développe une fonctionnalité sur une itération le délai d’attente pour la mettre en production est très long et pendant ce temps-là on obtient aucun feedbacks des utilisateurs. C’est du temps perdu !

Second problème : lorsque l’on déploie un certain nombre de fonctionnalités, même si les feedbacks seront positifs globalement, étant donné le nombre de fonctionnalités on ne saura pas laquelle plaît précisément aux utilisateurs

L’intérêt de déployer en continu c’est que l’on obtient plus de feedbacks des utilisateurs et plus rapidement : ce qui permet d’améliorer la qualité du produit.

Pourquoi le déploiement continu fait peur ?

Et oui, on l’a vu le déploiement continu permet un maximum de feedbacks donc assure un maximum de qualité pour le produit. Si c’est le cas, pourquoi alors est-ce que l’on ne déploie pas en continu à chaque fois ? Il s’avère que pour beaucoup le « Continuous Deployement » représente une énorme perte de temps. Pour la plupart, la mise en production met plusieurs jours voir même plusieurs semaines donc faire des MEP plusieurs fois par semaines dans ce cas peut facilement effrayer. Nous verrons par la suite comment gagner du temps avec le déploiement continu.

Une seconde raison pour laquelle nous avons peur du déploiement continu : c’est la qualité. On recense un certain nombre de buggs lorsque l’on met en production, donc la logique voudrait que : plus on déploie et plus le nombre de buggs augmente et résoudre tous ces bugg deviendrait très compliqué. Faux. Premièrement le code sera court donc moins de ligne = moins de buggs soit  moins de changements = moins de risques. Et deuxièmement la résolution de ces buggs sera beaucoup plus simple. En effet quand on fait de grands changements et que l’on déploie assez rarement le bugg sera plus difficile à trouver le temps que l’on se remette dans le bain d’un code qu’on aurait pu faire il y a plus d’un mois, tandis que si l’on déploie souvent tous les 2 jours par exemple, le code date de peu donc c’est encore tout frais dans la tête et on saura retrouver le problème rapidement.

Comment faire pour déployer en continu

La première chose à faire est de mettre en place une cadence. Définissez là. Par exemple : à partir de maintenant on déploie en prod toutes les 2 semaines et dans 6 mois on passe à toutes les semaines.

Globalement, pour le reste l’important est  d’automatiser. Automatisez tout ce qui peut être automatisé. Les tâches faites manuellement prennent beaucoup de temps et elles ne sont pas essentielles. La plupart peuvent être automatisées. Prenez le temps de mettre en place cette automatisation elle représentera un immense gain de temps sur le long terme. Par exemple : Faites des tests de perf automatisés, tests Javascript etc. Dans sa conférence à l’USI, Benoit Lafontaine vous explique toutes les méthodes pour automatiser.

.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *