Tout au long des années 2000, publier une nouvelle version d'un site web était un événement : les équipes d'ingénierie regroupaient des semaines de changements en une seule mise en production, planifiaient une interruption de service pour celle-ci et considéraient le jour du déploiement comme le moment où tout pouvait casser d'un coup. Etsy fonctionnait de la même manière, avec une équipe de déploiement dédiée faisant office de gardienne et des soirées tardives chaque fois qu'une version groupée tournait mal, car personne ne pouvait dire laquelle des dizaines de modifications simultanées avait provoqué la panne.

Le remède standard aux publications fragiles consistait à ajouter davantage de processus avant la publication — des cycles d'assurance qualité plus longs, davantage de validations, des environnements de préproduction plus grands — ce qui ajoutait du délai sans éliminer le risque réel : une publication livrait toujours quarante fonctionnalités d'un coup, si bien qu'un seul bug obligeait encore les ingénieurs soit à tout annuler, soit à fouiller sous pression dans l'ensemble du lot pour trouver la ligne fautive.

Le déploiement continu : des dizaines de petits déploiements en production par jour, chacun trivialement attribuable et réversible, remplaçant les soirées de publication redoutées.

Réduire la taille des lots de publication à un ou quelques changements par déploiement, rendant chaque échec trivialement attribuable et peu coûteux à annuler, au lieu d'ajouter davantage de processus avant publication.

Les grosses publications groupées enfouissent tout bug isolé parmi des dizaines de changements, ce qui rend l'attribution lente et coûteuse.

De petits lots signifient que chaque déploiement a au plus une cause plausible, si bien que les échecs sont instantanément traçables.

Les petits changements sont réversibles individuellement, si bien qu'un mauvais déploiement peut être annulé sans tout annuler.

Des déploiements petits et fréquents répartissent le risque sur de nombreux événements à faible enjeu, ce qui réduit la crainte et encourage des lots encore plus petits.

Lorsque les échecs sont difficiles à diagnostiquer, réduire la taille des lots au lieu d'ajouter davantage de processus avant la publication.

Au milieu de l'année 2010, la direction de l'ingénierie d'Etsy elle-même rapportait environ 200 déploiements en production par mois, un chiffre en hausse (« 204 déploiements en production en juillet, environ 30 % de plus qu'en juin »), chacun assez petit pour être rattaché à un seul ingénieur ; en 2014, l'entreprise citait publiquement environ 30 déploiements par jour.

VÉRIFIEZ LES SOURCES

Les sources

  1. Scaling startups Chad Dickerson (Etsy CTO, personal engineering blog) · blog.chaddickerson.com
  2. The Future Workplace Is Now: How Etsy Makes 30 Innovations Per Day Forbes · forbes.com