BT

Comment Etsy effectue des mises en production 50 fois par jour ?

par João Miranda , traduit par Dimitri Baeli le 30 mai 2014 |

Lors de la dernière conférence QCon London, Daniel Schauenberg a décrit comment Etsy, grâce à ses pratiques DevOps et Continuous Delivery peut effectuer 50 mises en production par jour. Pour réaliser ces changements à une telle vitesse sans prendre trop de risque, un canal de déploiement (deployment pipeline), de la métrologie (monitoring) et une collaboration à base d'IRC sont en place.

L'organisation des développements d'Etsy repose sur l'enchaînement de nombreux changements minimalistes en continu. Une conséquence directe est le besoin d'effectuer un nombre important de mises en production chaque jour. Selon les termes de Daniel Schauenberg, à chaque instant les développeurs doivent être en mesure de répondre à la question "Suis-je confiant pour mettre en production mon changement maintenant ?". Pour être confiant à tout moment, Etsy a mis en place tout un outillage et des pratiques : une communication obligatoire par IRC ; des machines virtuelles pour les développeurs ; de l'intégration continue ; des déploiement en un clic ; du monitoring applicatif et système ; des astreintes et des rétrospectives non punitives pour les devs et les ops.

Chaque développeur utilise sa propre KVM (Kernel-based Virtual Machine), configurée via Chef, un outil d'automatisation de configuration de système d'exploitation. Les mêmes recettes de configuration utilisées en production sont également utilisées sur les machines virtuelles des développeurs, ce qui veut dire que chaque développeur à une instance complète d'Etsy sur son poste. Chacun peut démarrer une machine virtuelle grâce à l'approche Virtual Madness, une application web qui automatise l'ensemble du processus.

Du coté de l'intégration continue, Daniel explique comment Try est au coeur de leur processus. Try est un outil qui permet au développeur de tester ses modifications avec Jenkins, l'outil d'automatisation utilisé chez Etsy, sans avoir à commiter dans le trunk. Try aide à garder un trunk propre et déployable, tout en autorisant en même temps les développeurs à tester leurs changements de façon fiable et rapide. L'usine logicielle doit être puissante pour supporter 150 ingénieurs, et plus de 14 000 exécutions de tests par jour. Les conteneurs Linux LXC répartissent la charge. Ils fournissent également l'isolation requise afin d'éviter toute collision entre des processus s'executant au même moment.

Le tunnel de déploiement (deployment pipeline) passe au travers de l'environnement de recette (staging) avant d'entrer en production. "Princess" est à tous les niveaux l'environnement de production, mais seulement les employés d'Etsy y ont accès. Et Deployinator est l'outillage de déploiement fabriqué et utilisé par Etsy qui lui donne la possibilité de mettre en production en 1-clic.

Les activations par configuration (feature flags) font partie intégrante du pocessus. Via son API dédiée aux features, Etsy est capable d'activer un A/B test, d'activer ou de désactiver entièrement une fonctionnalité, ou des variantes d'une fonctionnalité donnée.

Le Monitoring est la clé qui donne à l'équipe Etsy sa confiance dans la livraison continue (Continuous Delivery). Les développeurs suivent la performance de leur fonctionnalité, et tout le monde y a accès via des tableaux de bord. La politique d'Etsy par défaut est assez simple, tout ce qui peut être mis sous forme de graphe est mis sous forme de graphe. Avec le temps, le nombre de données suivies (métriques) a progressivement augmenté, donc Etsy a construit Kale pour aider à détecter des anomalies dans ces données. Toutes les traces (logs) sont accessibles via Supergrep, un parseur de logs via une application web qui aide à différencier une alerte et du bruit.

IRC est l'outil principal de communication pour l'ensemble d'Etsy et une clé de la culture collaborative. Il y a beaucoup de salles de réunion virtuelles (chat rooms), chacune avec un sujet spécifique. Par exemple, il y a #warroom où sont uniquement abordés les incidents de production. Ce canal (chat) est utilisé pour coordonner les investigations, les mesures à prendre et le suivi de résolution. #warroom, comme d'autres canaux, est l'endroit principal où les ingénieurs sont encouragés à y rôder, endroit propice à l'apprentissage.

Après chaque incident révélé ou frôlé, tout le monde est invité à faire un post-mortem. Les post-mortems sont des événements si importants dans la culture d'Etsy que même l'équipe de finance ou du support peuvent participer si elles le désirent. Les post-mortems sont censés être une occasion d'apprentissage, de ce fait, aucun reproche n'est fait lors de ces événements. Toutes les informations liées aux post-mortems sont enregistrées dans Morgue : dates ; sévérité ; logs IRC ; mesures ; actions correctives. Morgue est un autre outil construit par Etsy et dédié à la tenue des registres.

Etsy a aussi mis en place des astreintes pour la production, le développement, les paiements et le support. Les dévelopeurs sont généralement d'astreinte une semaine par mois, avec un système de rotation. L'idée est de conserver tout le monde au courant des contraintes journalières auxquelles le site fait face, ce qui permet de les prendre en compte beaucoup plus naturellement lors des développements et ainsi d'améliorer les pratiques en place.

Etsy reçoit 60 millions de visites uniques chaque mois, et sert 1,5 milliard de pages.

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Donnez-nous votre avis

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

...et les gros projets ? by Martin Sudmann

Là Etsy nous fait rêver avec ses micro-déploiements, mais comment font-ils avec des gros projets avec impact collatéral sur le site, du genre changement de la couche de persistance, changement du partenaire de paiement etc ?
Une autre question que je me pose : C'est bien, l'application identique à la prod sur le serveur des dev. Mais comment ils font pour la DB ? Un grand nombre de bugs du genre "ça marche en dev" sont dû à une DB trop légère, qui ne vit pas toutes les changements de la grosse DB en production.

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

1 Discuter

Contenu Éducatif

Rien ne serait possible sans le soutien et la confiance de nos Sponsors Fondateurs:

AppDynamics   CloudBees   Microsoft   Zenika
Feedback Général
Bugs
Publicité
Éditorial
InfoQ.com et tous les contenus sont copyright © 2006-2014 C4Media Inc. InfoQ.com est hébergé chez Contegix, le meilleur ISP avec lequel nous ayons travaillé.
Politique de confidentialité
BT