Lorsque l’on travaille sur des applications web orientées SaaS, on a la chance de pouvoir livrer rapidement et régulièrement de nouvelles fonctionnalités aux utilisateurs. C’est ce qui se cache derrière les concepts de livraison ou de déploiement continu. Pourtant, beaucoup d’équipes font des mises en production qui concentrent des semaines de développement. Et c’est à mon sens un problème.
Voir la publication originale
Cette dernière est republiée ici afin de ne pas dépendre entièrement d'une plateforme tierce.
Plus un déploiement est rare, plus il embarque de changements et plus le risque d’incidents augmente. Le volume de modifications impliqué peut drastiquement complexifier l’identification et la correction des bugs, car les développements liés peuvent parfois remonter à plusieurs semaines ou mois.
Les utilisateurs en sont les premiers impactés: apparition de nombreux bugs du fait de l’accumulation des développements et nouvelles fonctionnalités qui arrivent tardivement.
Côté développeur, les cycles longs sont souvent liés à des branches de développement avec une longue durée de vie. Si le travail est isolé le temps de conception, c’est lorsqu’il faut tout mettre en commun que les choses se compliquent: conflits de code à gérer et effets de bord potentiellement détectés à la dernière minute.
La réponse à ce problème est peut-être contre-intuitive, mais elle réside dans le fait de déployer plus souvent, des changements progressifs et incrémentaux. Les petits changements sont alors plus faciles à surveiller et à corriger. De plus, l’impact d’un bug se fait sur une surface réduite.
Déployer plus souvent, c’est également se poser moins de questions sur les potentiels impacts de ce que l’on va livrer. J’ai, par exemple, vu des équipes devoir « patcher » la version d’un outil datant de plusieurs mois et être effrayées à l’idée de devoir déployer les nouveaux changements.
Il est pourtant possible de limiter les erreurs. Il existe de nombreuses techniques permettant de livrer du code progressivement. On peut, par exemple, évoquer le mécanisme de « features flags » qui permet d’activer (ou non), de manière progressive (ou non), des fonctionnalités pour un périmètre d’utilisateur défini.
Il ne faut pas oublier que moins on déploie et plus on a peut de déployer. Et plus on a peur de déployer, moins on déploie. Il est donc essentiel de livrer petit et souvent.
