5 bonnes raisons de déployer en continu

Depuis la présentation retentissante de John Allspaw à Velocity 2009 sur la collaboration entre dev et ops, où il explique que chez Flickr le rythme de déploiement en production dépasse les 10 par jour, on entend beaucoup parler de "continuous delivery" et "continuous deployment". Ce dernier se différencie par une automatisation complète de la chaîne de fabrication et déploiement entre le commit du développeur et le déploiement en production, alors que le "continuous delivery" préconise des interventions manuelles (simples "push-button") pour approbation humaine de certaines étapes : tests fonctionnels manuels, test d'usabilité, contrôle des déploiements par le marketing, etc. J'emploierai le terme "déploiement continu" dans cet article pour regrouper les deux notions. Quelques sociétés nous font part de leur retour d'expérience : pour exemple un présentation du QCon San Francisco 2010 où il est cette fois question de 50 déploiements par jour! (rien que ça...) Ou encore plus récemment le talk de Facebook sur la culture et les outils qui leur permet de déployer tous les jours.

Comme beaucoup, je me suis d’abord demandé plusieurs fois : “Franchement... quel est l’intérêt de déployer tous les jours ?”. Je suis aujourd’hui convaincu que ce n’est pas un délire de geek ou une volonté d’être inscrit aux Guinness World Records. Voici les 5 raisons majeures de s'y intéresser.

1. L'innovation au cœur de la stratégie concurrentielle

Tout va très vite de nos jours; la concurrence est rude, les besoins évoluent rapidement, les modes se font et se défont sur le web... dans certains contextes, si vous n'êtes pas "time to market", vous êtes morts! Alors évidemment le déploiement continu n’aide pas à coder plus rapidement pour s’adapter à ces changements. L’idée est de construire constamment une application prête pour la production, afin de se donner les moyens de pouvoir la déployer à tout instant et de ne plus être nécessairement contraint par un planning sur 6 mois qui définit des lots de fonctionnalités impliqués dans telles versions majeures. De plus, il nous permet d'optimiser le lead time en réduisant les coûts de transactions et ainsi de répondre facilement à cette question que nous pose Mary Poppendieck :

How long would it take your organization to deploy a change that involves just one single line of code?

Sans tomber dans la dizaine de déploiements quotidien, le déploiement fréquent est un bon outil pour expérimenter des fonctionnalités, de préférence sur un groupe d'utilisateurs avant de déployer plus largement. En effet, à la manière des méthodes de développement agiles qui permettent de réduire la boucle de feedback et ainsi réduire le risque que l'application ne réponde pas aux spécifications au bout du tunnel (ou que finalement les spécifications n'étaient pas bonnes au vu du résultat...), le déploiement continu permet d'obtenir un feedback terrain extrêmement précieux issu de l'utilisation réelle de l'outil en production. Bien sûr le déploiement en lui-même n'est pas suffisant, il faut y ajouter une bonne dose de supervision applicative rendant possible l'analyse des comportements utilisateurs et la performance métier. Le concept Lean Startup repose d'ailleurs essentiellement sur cette boucle de feedback :

Illustration issue d'une présentation de Eric Ries (fondateur du Lean Startup)

2. Eliminer les gaspillages (Lean)

Voici un extrait issu d'un article de notre blog "Qu'est-ce que le Lean ?" :

Eliminer le gaspillage sur le flux de valeur. Il faut se concentrer sur ce qui crée la valeur pour laquelle le client de l’entreprise est prêt à payer. Toute l’entreprise est au service de cette création de valeur. Elle est créée le long d’un flux de transformation. Dans l’idéal, ce flux est tiré et sans stock pour réagir aux fluctuations de la demande et minimiser l’investissement. Cela signifie que l’on ne commence à produire quelque chose que lorsqu’il y a une demande. On ne produit alors que ce qu’il faut pour cette demande.

En effet, du code non déployé n'est rien de plus que du stock puisqu'il n'apporte aucune valeur pour le client. Il ne rapporte donc aucun bénéfice pour l'entreprise.

3. Evolution incrémentale (plutôt que radicale) du produit

En tant qu’utilisateur, vous préférez :

• les applications type “béta permanente” qui vous livrent régulièrement des nouvelles fonctionnalités ?
• ou l’approche “brand new app” tous les 6 mois/un an avec changement d’ergonomie et un lot de nouvelles fonctionnalités qui nécessitent une formation de 2 jours pour vous y adapter ?

J’ai vécu la deuxième approche régulièrement dans une vie antérieure pour des applications de gestion internes... c’était à chaque fois un supplice pour moi de devoir me réadapter à l’outil et perdre un temps fou en productivité. Et oui, l’homme n’aime pas les gros changements quand ils sont imposés et que le gain apporté par l'évolution n'est pas significatif.

A l’inverse, le déploiement continu ne doit pas faire apparaître trop de changements fréquents à l’utilisateur qui risque de se sentir perdu à chaque visite. Mais ce risque est mineur, ce n’est pas parce que vous déployez 10 fois par jour que les développeurs vont implémenter 10 nouvelles fonctionnalités par jour! Cela ne doit pas remettre en cause la définition d'un planning de déploiement des fonctionnalités.

4. Plus de deploy = moins de code = moins de risque = plus de stabilité !

Comme dans tout système dynamique, l'équilibre entre le changement et la stabilité est une question délicate. On a tendance à croire instinctivement que plus on introduit du changement dans un système, plus on risque de compromettre sa stabilité. En fait, ça dépend de la nature du changement... Par contre, John Allspaw fait le constat suivant : plus les déploiements sont espacés dans le temps, plus la quantité de changement est importante, et plus le temps de résolution (TTR) de problème est long. Il démontre donc que déployer plus fréquemment (donc moins de ligne de code par déploiement) permet de réduire le TTR de façon conséquente :

Illustration issue d'une présentation de John Allspaw

Pourquoi? Deux raisons à cela :

• moins il y a de lignes de code déployées, plus le temps de détection (TTD) de l'origine du problème est rapide
• le même enjeu qui nous pousse à faire plus de test pour avoir du feedback plus rapide ("fail fast") : plus un bug est découvert tard, plus il est couteux à corriger.

Il va sans dire que le déploiement continu permettra de réduire encore le TTR en déployant le fix (rollback ou rollforward) en un clic! :)

5. Même pas peur de déployer en prod

Sans rentrer dans le détail de l’implémentation qui fera l’objet d’autres articles, il est évident que cette démarche repose essentiellement sur l’automatisation. C'est grâce à cette automatisation qu'on arrive à transformer le processus de déploiement, habituellement jugé délicat, voire risqué, en ce qu'on peut appeler un "non-évènement".

Lorsque l’on déploie en production plus d’une dizaine de fois par jour, il faut :

• non seulement que le processus de fabrication soit fiable, c'est à dire que l’application soit constamment prête pour être déployée en production avec un niveau de qualité requis, garanti par une bonne couverture de tests automatisés
• mais également que le processus de déploiement soit le plus rapide, fiable et répétable possible pour limiter au maximum les indisponibilités et risques de panne.

En effet, plus on pratique cet exercice, plus on ressent le besoin de l'automatiser car trop laborieux manuellement, moins on a cette impression de naviguer vers l'inconnu car l'opération devient fiable et donc moins de raison de craindre le fameux "last mile". Cela présente donc au final un autre avantage et pas des moindres pour tous les acteurs de la livraison en production : diminuer le stress et les sueurs froides.

Conclusion

Le déploiement continu peut jouer un rôle majeur dans la performance d'une entreprise. Vous l'aurez compris, cette technique est particulièrement adaptée pour des applications Web. Déployer une application "client lourd" 50 fois par jours n'est clairement pas une bonne idée, mais différents mécanismes (détaillés dans cet article) offrent néanmoins la possibilité d'accélérer le rythme des mises à jour.

Malheureusement, la démarche de déploiement continu est loin d'être simple à mettre en œuvre, dépendante de l’organisation en place et du niveau de coopération entre les différents acteurs du delivery. Elle est par exemple très adaptée aux entreprises de type startup. En revanche l'appliquer dans des grandes entreprises nécessitera un bon niveau de maturité, de communication et de confiance entre les équipes de développement/test (build) et de production (run) : leitmotiv du mouvement DevOps. Les outils jouent également un rôle majeur pour industrialiser le processus, nous aurons tout le loisir d'y revenir d'en d'autres articles!