Devoxx France 2015 Jour 3 : Livrer chaque jour ce qui est prêt

Une présentation à Devoxx France 2015 a retenu mon attention. Il s’agit de celle de Dimitri Baeli et Benjamin Degerbaix qui travaillent chez LesFurets.com (un comparateur d’assurances) et qui nous ont présenté leurs recettes pour passer d’une livraison par mois en 2012 à une livraison par jour depuis 2014.

Contexte

LesFurets c’est :

• 6 produits d’assurance (Auto, Santé, Moto, Habitations, Emprunteur, Forfaits)
• une appli GWT (Java pour le back et le front)
• des serveurs Tomcat
• 400k lignes de code
• 40k test unitaires
• 200 tests Selenium
• une petite équipe (33 personnes dont 22 développeurs)
• 4 feature teams (composées de Product Owners et développeurs)

Entre 2012 et 2014, ils sont passés d’une livraison par mois en Scrum à une livraison par jour en livrant “ce qui est pret” (mode marathon).

Le temps pour qu’un commit arrive en prod (lead time) est passé en moyenne de 15 jours à 2 jours.

Mise en oeuvre

Principes fondateurs

Les point importants pour que le continuous delivery fonctionne sont :

• Build rapide : si le build est trop long, on n’a pas de retour rapide pour corriger les problèmes.
• Build robuste : tout le monde travaille sur la même base de code, il faut un time to repair rapide pour que le build soit (presque) toujours au vert.
• Déploiements simples et automatisés : moins il y a d’intervention humaine plus il est facile de livrer ; chaque dev a également un DNS qui pointe sur sa machine et on peut tester facilement sa version.
• Monitoring de production et alertes : trouver les bugs vite et les corriger vite. Tout le monde doit pouvoir lire le monitoring, c’est pourquoi du monitoring fonctionnel a été mis en place.
• Analyse des causes racines : pour supprimer définitivement le bug.

Une fois qu’une fonctionnalité est prête, on prévoit sa livraison le lendemain. On peut parler de daily delivery. Ce n’est pas du continuous delivery comme chez GitHub qui livre 100 fois par jour mais cela s’en approche et cela permet surtout d’avoir une grande réactivité.

Cette grande réactivité n’est possible que si la construction de l’application est très rapide et donc que les tests s’exécutent rapidement. C’est pourquoi il y a eu un gros travail sur l’optimisation de leur exécution :

• le build (compilation+tests) est passé de 15 à 3 minutes
• les tests fonctionnels (Selenium) sont passé de 1 heure à 10 minutes

Chaque jour est ainsi une occasion de s’améliorer. C’est un développeur, jamais le même, qui est responsable de la livraison en production. C’est également le développeur qui valide que sa fonctionnalité marche : validation technique par un autre développeur et validation fonctionnelle par un PO.

Ces livraisons multiples permettent :

• un retour rapide : utile pour améliorer ou abandonner la fonctionnalité
• une analyse plus facile d’une anomalie introduite par une livraison

Gitflow

Pour pouvoir livrer par petits incréments, chaque fonctionnalité est développée dans une feature branch en utilisant le modèle de développement Gitflow et il est fait en sorte qu’il n’y ait pas d’adhérence entre fonctionnalités, ce qui gênerait leur livraison séparée. Si deux fonctionnalités ne peuvent être livrées séparément, c’est qu’elles n’en sont qu’une seule.

Octopus

L’integration continue utilise Octopus pour faire du continuous merge. Octopus est un outil développé par LesFurets. Il permet de merger toutes les features branches avec le master dans un commit temporaire et c’est celui-ci qui est déployé sur l’environnement de staging. On peut ainsi, via les tests Selenium, détecter un effet de bord de ce regroupement des features.

Zeno

Lors de la création d’une release seules les features prêtes sont mergées avec le master par Octopus. Ensuite seront lancés les test Selenium, puis, des tests de non régression UI utilisant Zeno qui est un outil également développé en interne et permettant de comparer les rendus en fonction des environnements (staging, pre-prod, prod) et des résolutions (desktop, mobile, tablette). Il fonctionne par comparaison d’images en prenant une capture d’écran de toutes les pages de l’application afin de détecter un éventuel changement dans le rendu.

Infra as code

La configuration des différents environnement est sous Git. Un bug de configuration est un bug de code comme un autre.

Selenium

Les tests Selenium prennent 10 minutes mais cela n’a pas toujours été le cas. C’est seulement depuis qu’ils sont très rapides que la mise en production journalière est possible.

• Sur une seule machine, ces tests prennent 6 heures.
• Sur un grid Selenium, sur un seul serveur, ils prennent 1 heure.
• Sur un grid Selenium en RamFS, sur ce même serveur, ils ne prennent plus que 10 minutes.

C’est en observant une grosse activité disque couplée à des instabilités que l’idée de monter le disque en RAM est apparue. Depuis, plus de soucis de stabilité et le temps d’exécution a été divisé par 6.

Déploiement

Le déploiement en production est de type Blue/Green et permet de n’avoir aucun downtime:

• On démarre les nouvelles instances de Tomcat.
• Les nouvelles sessions HTTP se déroulent sur les nouveaux serveurs.
• On attend la fin des anciennes sessions HTTP (30 minutes d’inactivité).

Si évolution de la base de données, la livraison peut être faite en 2 étapes : on livre d’abord une version qui contient juste les changement de base de données et qui reste compatible avec l’application actuelle. Ensuite, on livre l’application qui exploite la base de données modifiée. Le rollback reste donc possible de la version n+1 vers la version n.

Monitoring

Pour assurer le suivi de prod on dispose :

• d’indicateurs techniques (sondes zabbix)
• d’indicateurs fonctionnels (sondes zabbix)
• d’emails synthétisant les erreurs survenues.

Si un incident de prod survient, il donne lieu à un Post-Mortem et on analyse la cause profonde. Ne pas mettre en prod est considéré comme un incident de prod.

Conclusion

Cette présentation donne l’impression que livrer tous les jours est facile tant les recettes présentées sont pleines de bon sens. Néanmoins, on sent que ces pratiques ont mûrit au fil du temps notamment grâce aux ouvrages de référence cités dans la présentation. En dehors de l’intérêt du retour rapide sur les nouvelles fonctionnalités pour le métier, le principal intérêt que je vois à livrer régulièrement est que la mise en production est moins douloureuse et l’effort plus lissé dans le temps. Il faut être courageux et accepter qu’il va y avoir des problèmes et se mettre en position de les résoudre rapidement et de faire en sorte que cela n’arrive plus. Tout ceci permet l’amélioration continue car on va pouvoir très souvent corriger son processus de livraison d’une application.

Les slides sont en ligne.