Les Patterns des Grands du Web – Continuous Deployment

Description

Dans l'article « Bêta perpétuelle », nous avons vu que les géants du Web améliorent leur produit de façon permanente. Mais comment arrivent-ils à livrer fréquemment ces améliorations alors que dans certaines DSI, la moindre modification peut prendre plusieurs semaines à être déployée en production ?

La plupart du temps, ils ont instauré un processus de déploiement continu (continuous deployment), selon deux modalités possibles :

• Soit de façon totalement automatisée – une modification de code est automatiquement vérifiée puis, le cas échéant, déployée en production.
• Soit de façon semi-automatisée : il est possible à tout moment de mettre en production le dernier code stable en cliquant simplement sur un bouton. On parle alors de « one-click-deployment ».

Evidemment, la mise en place de ce pattern demande certains pré-requis…

Mais pourquoi déployer en continu ?

La motivation première du déploiement continu est d’améliorer le Time To Market, mais aussi de se donner autant d’occasions de tester des hypothèses, de les valider et au final d’améliorer son produit.

Effectivement, imaginons une équipe qui met en production tous les 1^er du mois (ce qui est déjà une fréquence élevée pour beaucoup de DSI) :

• J’ai une idée le 1^er.

• Avec un peu de chance, les développeurs peuvent l’implémenter pendant les trente jours qui restent.

• On met en production comme prévu dans le plan de release mensuel le 1^er du mois suivant.

• Pendant un mois, on collecte les données pour finalement s’apercevoir que l’on doit améliorer l’idée de base…

• Il faut alors attendre un nouveau mois pour mettre en œuvre cette future amélioration, soit trois mois au final, pour avoir la fonctionnalité stabilisée.

Dans cet exemple, ce qui nous empêche d’aller vite, ce n’est pas le développement, mais bien le processus de livraison, et le plan de release.

Déployer en continu permet donc d’améliorer le Time To Market, mais aussi d’accélérer les cycles d’amélioration du produit.

On peut ainsi améliorer le cycle bien connu du Lean Startup :

Figure 1.

Quelques définitions

On entend souvent parler indifféremment de « Continuous Delivery » et « Continuous Deployment », pour éviter les erreurs d’interprétation, voici notre définition.

À chaque commit (ou par intervalle de temps), le code est :

• Compilé, testé, déployé sur un environnement d’intégration = Continuous Integration
• Compilé, testé, livré à l’équipe suivante (Tests, Qualification, Mise En Production, Ops) = Continuous Delivery
• Compilé, testé, déployé en production = Continuous Deployment

Attention, il ne s’agit pas ici de dire que le Continuous Delivery et la Continuous Integration ne servent à rien. Bien au contraire, ce sont des étapes essentielles, et le Continuous Deployment n’est que l’extension naturelle du Continuous Delivery qui est lui-même l’extension naturelle de la Continuous Integration.

Et la qualité ?

L'une des objections courantes lorsque l’on parle de Continuous Deployment est le manque de qualité : ne risquons-nous pas de livrer quelque chose d’incorrect, de livrer des bugs ?

Tout comme avec la Continuous Integration,  on ne bénéficiera pleinement du Continuous Deployment que si l’on est capable d’être sûr du code à tout moment. Ceci implique d’avoir une couverture de tests (unitaires, d’intégration, de performances, etc.) très complète. Outre les tests unitaires, inévitables, on trouvera donc toute une série de tests automatisés comme :

• Tests d’intégration (Fitnesse, Greenpepper, etc.)
• Tests IHM (Selenium, etc.)
• Tests de performance (Gatling, OpenSTA, etc.)

L’automatisation des tests peut sembler coûteuse, mais quand l’objectif est de les exécuter plusieurs fois par jour (IMVU lance 1 million de tests par jour), le retour sur investissement est très rapidement positif. Certains, comme Etsy, n’hésitent pas à créer et à partager des outils pour coller aux mieux à leur besoin d’automatisation et de test^[1].

De plus, lorsqu’on déploie tous les jours, la taille des déploiements est évidemment plus petite que lorsqu’on déploie tous les mois. Et sur des petits déploiements, le TTR (T_ime To Repair_ ou temps de réparation) est plus petit, comme on peut le voir sur la figure 2.

Figure 2 . Source : http://www.slideshare.net/jallspaw/ops-metametrics-the-currency-you-pay-for-change-4608108, modifiée.

Etsy donne une bonne illustration de la confiance que l’on peut avoir dans le code et dans la capacité de corriger rapidement. En effet, ils ne prévoient pas de mécanismes de rollbacks : « We don’t roll back code, we fix it » (« on ne fait pas de retour arrière sur le code, on le corrige »). Selon un de leur employé la plus longue durée de réparation d’un bug critique fut de quatre minutes.

Les gros changements créent de gros problèmes, des petits changements créent de petits problèmes.

Chez qui ça fonctionne ?

De nombreux géants du Web ont implémenté avec succès le Continuous Deployment, voici quelques chiffres des plus représentatifs

• Facebook, très agressif sur l’automatisation des tests, effectue 2 déploiements par jour.
• Flickr utilise massivement le Feature Flipping afin de se passer de branches de développement et déployer plus de 10 fois par jour. Une page affiche les détails du dernier déploiement : http://code.flickr.com
• Etsy (site de commerce en ligne), a investi énormément dans ses tests automatisés et ses outils de déploiement et effectue plus de 25 déploiements par jour.
• IMVU (Site de jeux sociaux et avatars 3D), exécute plus d’un million de tests par jour et réalise environ 50 déploiements par jour.

Et chez moi ?

Tout d’abord, estimez (ou mieux, mesurez !) le temps nécessaire à vous et votre équipe pour livrer une simple ligne de code jusqu’en production, en respectant le processus standard évidemment.

Mettre en place le Continuous Deployment

La mise en place d’une « Usine de Développement » est la première étape du Continuous Deployment.

Afin de pouvoir aller plus loin, il est essentiel de s’assurer que l’ensemble des tests réalisés couvrent une large part de l’application. Si certains acteurs n’hésitent pas à coder leur propres frameworks de tests (Netflix a initié le projet « Chaos Monkey » qui éteint des serveurs aléatoirement), on peut se baser sur des frameworks existants allant de JUnit à Gatling en passant par Selenium. Afin de réduire le temps d’exécution des tests, IMVU répartit ses tests sur pas moins de 30 machines. D’autres utilisent les services Cloud comme AWS afin d’instancier des environnements de test à la volée et paralléliser l’exécution des tests.

Passer au Continuous Delivery

Une fois que l’usine de développement produit des artefacts suffisamment testés, celle-ci peut être étendue afin de livrer ces artefacts à l’équipe qui va déployer l’application sur les différents environnements. À cette étape, on est déjà dans le Continuous Delivery.

Maintenant, cette dernière équipe peut enrichir l’usine afin d’y inclure les tâches de déploiement. Ceci nécessite évidemment que différentes tâches soient automatisées, comme la configuration des environnements, le déploiement des artefacts constituant l’application, la migration des schémas de bases de données et bien d’autres encore. Attention aux scripts de déploiement ! Il s’agit de code, et comme tout code, il doit répondre aux standards de qualité (utilisation d’un SCM, tests, etc.).

Forcer le Continuous Deployment

Une solution plus radicale mais intéressante est de forcer le rythme de livraison, par exemple toutes les semaines, afin de provoquer les changements.

Patterns connexes

Lorsque l’on met en place le Continuous Deployment, plusieurs patterns sont inévitablement tirés et notamment :

• Le Zero Downtime Deployment, car si une interruption de service d’une heure n’est pas problématique lorsque l’on livre tous les mois, elle peut le devenir quand on passe à une livraison hebdomadaire ou quotidienne.
• Le Feature Flipping, car une livraison régulière entraîne fatalement la livraison de fonctionnalités non terminées ou avec des erreurs, il faut donc pouvoir désactiver instantanément ou en avance les fonctionnalités posant problème.
• Devops évidemment puisque le Continuous Deployment en est l’un des piliers.

Retrouver toutes les pratiques des Géants du Web sur le site dédié (www.geantsduweb.com) : pdf de l'ouvrage à télécharger, vidéo et compte-rendu de la présentation "Décrypter les secrets des Géants du Web"

Sources

• Chuck Rossi, Ship early and ship twice as often, 3 août 2012.

• Ross Harmess, Flipping out, Flickr Developer Blog, 2 décembre 2009 .

• Chad Dickerson, How does Etsy manage development and operations?, 04 février 2011.

• Timothy Fitz, Continuous Deployment at IMVU: Doing the impossible fifty times a day, 10 février 2009.

• Jez Humble, Four Principles of Low-Risk Software Releases, 16 février 2012.

• Fred Wilson, Continuous Deployment, 12 février 2011.