Si, au cours de votre carrière, vous avez travaillé sur une application web en production, avec plus de quelques utilisateurs occasionnels, vous avez probablement une petite idée des contraintes que cela peut engendrer. Pour les autres, l’ignorance serait-elle le bonheur ?

Maintenir la disponibilité de l’application pour les utilisateurs durant leur période d’activité normale pousse généralement l’ensemble des équipes qui travaillent à faire évoluer le produit et à s’organiser autour de cette contrainte : les mises en production (livraisons des nouvelles fonctionnalités ou mises à jours) sont planifiées la nuit ou les weekends, des équipes se retrouvent d’astreinte pour surveiller en permanence que tout fonctionne, etc…

Une problématique complexe, des objectifs simples

Si cette organisation est très propice à la bonne marche de l’application, la qualité de vie des fragiles et sensibles êtres humains qui s’en occupent est, elle, nettement dégradée. Chez Jenji, nous sommes convaincus que ce n’est pas une fatalité ! Nous avons tout mis en oeuvre pour atteindre (et conserver, le plus important) un équilibre sain et durable entre une application qui évolue rapidement et une équipe de développement heureuse et bien dans ses baskets.

Quand le chef cherche un volontaire pour une mise en prod'

Dans cet esprit, nous avons, dès la conception de l’application, décidé de porter une attention particulière à la problématique des mises en production. Et nous nous sommes fixés un objectif simple : ces dernières se feront en semaine et en journée. Sans interruption de service bien entendu.

En dehors des applications mobiles, Jenji est schématiquement constitué de 2 types d’unités applicatives. Le 1er est une application web constituée du backend, partie serveur écrite en Java, et du frontend, application exécutée par les navigateurs écrite en Javascript/TypeScript. Le 2e type est un micro-service asynchrone, une petite application dédiée à une tâche très précise (création des miniatures des reçus, exécution des exports, envoi des emails, etc...). Par nature, ces services sont en nombre important et toujours croissant. Nous reviendrons sur le pourquoi et le comment de cette architecture dans un autre billet, mais vous devez percevoir que nous avons dû mettre en place des politiques de déploiement adaptées à ces 2 classes d’applications.

Déploiement de l’application web

Le déploiement de l’application web, se fait en milieu de semaine, en début d’après-midi. Ce timing nous assure d’avoir le temps de repérer et de réagir à un éventuel souci, sans avoir à passer la nuit au bureau. L’opération est indolore et dure au maximum 1 heure, tests post-déploiement compris.

En trois clics, le backend, hébergé sur le service AWS ElasticBeanstalk est mis à jour progressivement et automatiquement. Les nouvelles machines démarrent, puis le load-balancer (répartiteur de charge) leur transfère une part croissante du trafic tout en surveillant que tout se passe sans encombre. Pour finir, quand toute la charge est supportée par les nouvelles instances, les anciennes sont arrêtées. Le tout se déroule la plupart du temps en moins de 20 minutes.

Pour le frontend, c’est tout aussi simple. En quelques clics, notre outil d’intégration continue déploie la nouvelle version sur le service de stockage de fichiers S3. Le service Cloudfront met ensuite à disposition automatiquement ces nouveaux fichiers aux navigateurs qui se connectent.

Simple et indolore. A tel point que n’importe qui dans l’équipe est capable de le faire. Même les stagiaires le pourraient, mais ne tentons pas le diable !

Quand notre mise en prod' s'est bien déroulée

De plus, l’opération est quasiment impossible à déceler pour les personnes utilisant activement l’application durant cette période. Les développements sur le backend sont pensés pour toujours être compatibles avec l’ancienne version du web. Et la nouvelle version du frontend n’est visible qu’après un rechargement de la page dans le navigateur (ce qui arrive plutôt quand le navigateur redémarre le lendemain).

Mise à jour des micro-services

Ces services sont par définition… micros. Quelques centaines de lignes de code tout au plus. Ils se présentent sous forme de services ECS (Elastic Container Service). Pour chaque service, ECS est responsable de maintenir un nombre défini de tâches identiques en fonctionnement. Et nous concevons ces tâches pour que tout arrêt intempestif (et redémarrage automatique par ECS donc) n’ait pas de conséquence sur les données en cours de traitement.

Une mise en production d’un de ces services ne revient alors qu’à créer une nouvelle version de la tâche associée, d’arrêter les instances existantes et d’en démarrer autant avec la nouvelle version de la tâche. L’interruption est limitée à quelques secondes (pour le service concerné uniquement) et là aussi presque imperceptible pour un utilisateur.

Pour ces services, les règles de mises en production sont simples : en fonction des besoins mais jamais en fin de journée. Et nous évitons le vendredi dans la mesure du possible.

Des bénéfices nombreux

Les conséquences de cette simplicité de déploiement sont multiples, à la fois directes et indirectes.

La première est le rythme des mises à jour: pourquoi se priver et n’en faire que tous les 1 à 3 mois ? Pour l’application web Jenji, nous sommes arrivés sur un rythme qui nous convient bien : toutes les semaines ! Plus souvent, nous manquerions de matières. Moins souvent, nous prenons des risques sur les évolutions parallèles. Les fonctionnalités sont aussi moins “fraîches” dans les esprits, ce qui augmente le coût des corrections en cas de bug.

La seconde : les bugs justement. Ils arrivent même chez les meilleurs (ceux qui vous disent le contraire, vous cachent des choses). La solution : corrections, tests, déploiement. Le tout peut prendre moins d’une heure pour les bugs simples .
Et ensuite, viennent les conséquences indirectes. Une fois ces opérations entrées dans la routine, la peur et le stress associés disparaissent. Cela vous paraît négligeable ? Vous avez de la chance d’être aussi zen ! Les autres, vous savez de quoi je parle : cette petite perle de sueur sur la tempe au moment de lancer le déploiement, les doigts croisés en espérant que tout se passe bien sur toutes les machines… Et ces questions qui tournent en boucle dans le cerveau torturé des développeurs : “les reboot manuels sinon... Et le package, il a bien buildé j’espère, pas comme la dernière fois ? Et c’est quoi le 7e script à lancer déjà ? Il fallait pas faire un changement de configuration sur cette release aussi ?”

Quand je m'apprête à déployer une grosse mise à jour

Pour une application utilisée quotidiennement par une partie de ses utilisateurs, il est aussi important de conserver une continuité dans la logique d’utilisation. Effectuer des livraisons très espacées créé des changements importants auxquels les utilisateurs n’ont d’autre choix que de s’adapter brusquement. Avec des livraisons fréquentes, les évolutions sont progressives et les changements sont introduits petit à petit.

Donc, pour résumer, chez Jenji nous prenons soin de la vie et de la santé mentale de nos équipes et de nos utilisateurs ! Vous aussi testez la “Jenji Zen Attitude” !

Quand une mise en prod' s'effectue sans souci

Pour faciliter la gestion de vos notes de frais, n’hésitez pas à tester notre solution en la téléchargeant gratuitement. Et si l'aventure vous tente, nous vous attendons ! A vous de jouer : rejoignez-nous !

Télécharger pour iPhone
Télécharger pour Androïd


Article co-rédigé avec Guillaume Tinon, VP of Engineering @Jenji.