Comment réduire le time to market, cet intervalle de temps qui sépare une idée métier de sa concrétisation ? Dans ce KM Time (session interne de Knowledge Management), Clément Cunin expose les grands principes du Continuous Delivery.

All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing that time line by attacking waste within the processes across this time line

Taiichi Ohno, Toyota Production System, 1988

Taiichi Ono cible ici un processus sur toute sa longueur : de la commande client à l’encaissement, l’idée est de réduire cet intervalle en s’attaquant aux pertes de temps. Il ne s’agit pas d’étudier les comportements individuels. Pour prendre l’analogie d’une course en relais, ce qui compte n’est pas la performance de chaque coureur, mais la vitesse à laquelle le bâton circule.

Dans le cas du développement logiciel, le schéma ci-dessous donne une bonne idée des différences entre le temps de travail effectif et le temps d’attente.

Le plus souvent, on constate que si les équipes métier sont en attente de changement, les équipes techniques demandent plutôt de la stabilité. Toute la question est donc de savoir comment apporter du changement sans remettre en cause la stabilité du système. Si les releases importantes sont le plus souvent effectuées le weekend, c’est parce qu’elles apportent beaucoup de changements. On multiplie ainsi les risques d’erreur, et un bon nombre de releases conduit à des incidents de production. De fait, la release devient un évènement stressant. C’est ici qu’intervient le Continuous Delivery, pour toute la partie de mise en production. Pour le reste, on pourra par ailleurs se référer aux méthodes Agile, Scrum, Lean, Kanban, etc.

La méthode repose sur 8 piliers :

1- La release doit être entièrement reproductible. Les opérations pour passer du code à une version en production doivent être ré-exécutables et produire le même résultat.

2- Pour que le résultat soit reproductible, il faut automatiser.

3- Tout doit être fait en gestion de configuration : code, configuration de l’application, configuration des machines, etc. Toutes ces informations doivent être traçables.

4- Ce qui est difficile doit être fait souvent : plus une tâche difficile est exécutée régulièrement, plus on la fera aisément avec le temps. Si le process de release est difficile, faites-le souvent !

5- La qualité se construit avec le produit : il est essentiel de mettre en place les tests permettant de valider le bon fonctionnement de l’application dès le début de son développement.

6- La fonctionnalité n’est effective que lorsqu’elle est utilisable par le métier. Et donc, quand elle est en production. C’est quand on reçoit les clés de sa maison qu’on est propriétaire, pas quand on signe chez le notaire !

7- L’ensemble de l’équipe est responsable de la release : les MOA ont spécifié le besoin, les développeurs l’ont codé, la production l’a démarrée…si un seul de ces éléments fait défaut, la fonctionnalité ne sera pas correctement utilisable par le métier. C’est une activité d’équipe.

8- Agilité et amélioration continue : la mise en place de cette approche n’est jamais terminée. On peut toujours l’optimiser, chercher des axes d’amélioration, rajouter des tests pour éviter des erreurs

L’application de ces principes amène à la création d’un pipeline de développement : commit, compilation, vérification des tests unitaires, analyse, build du package, acceptance tests, tests de charge (éventuellement), tests manuels suivant les cas, puis release. Le découpage en tâches permet ainsi d’avoir un feedback le plus rapide possible : en cas d’erreur, on a l’information très rapidement.

Clément a d’ailleurs réalisé à cette occasion une démonstration de ce pipeline sur Jenkins. D’autres outils existent (AWS – Bamboo – Chef – Crucible – Fisheye – git – Jenkins – Maven – Puppet – RedHat Kickstart – Selenium – soapUI – Sonar – SVN), mais il faut garder à l’esprit que le Continuous Delivery concerne tout autant les outils que les individus et les processus.

C’est cette méthode qui permet à des acteurs majeurs de l’Internet comme Facebook ou Flickr de réaliser plusieurs déploiements par jour. Amazon, par exemple, déploie un nouveau code en production toutes les 11.6 secondes ! (source : Infinite Undo) ; dans la vidéo ci-dessous, Jon Jenkins vous donnera le détail des statistiques de déploiement chez Amazon.