Plongée au cœur de l’application Mailgun : 2e partie – Une exécution triomphante

Lorsque nous avons entamé la refonte de l’application Mailgun il y a de cela trois longues années, nous avons consacré une bonne partie de notre temps aux preuves de concept, à la planification et aux tests. Notre objectif ultime ? Créer une expérience applicative qui met en valeur les différents produits de notre gamme, permet de naviguer facilement entre eux et garantit leur support de manière efficace grâce à une infrastructure unique.

L’envergure de ce projet était telle qu’il nous a fallu plus d’un article pour décrire les raisons de cette refonte, notre méthode, les leçons que nous en avons tirées et ce que l’implémentation de cette nouvelle technologie signifie pour notre avenir. Dans la première partie de cette aventure épique, « 1re partie : d’excellentes idées », nous vous avons fait remonter le temps pour observer notre processus. Nous avons partagé avec vous nos réflexions et les raisons de cette initiative, et nous vous avons présenté les défis auxquels nous savions que nous allions être confrontés.

À présent, dans la « 2e partie : une exécution triomphante », nous vous emmenons dans les coulisses pour vous montrer comment nous avons implémenté ce projet, comment nos équipes ont collaboré et le rôle que le design a joué dans notre réflexion.  Il y a du drame, il y a des migrations… et probablement un peu trop de références à la science-fiction. Rejoignez-nous pour l’aventure.

La volonté de mettre à jour l’application Mailgun a été motivée par les limites de notre ancienne infrastructure, en particulier avec notre organisation en polyrepo, où chaque projet front-end avait son propre dépôt, même si de nombreux projets répétaient les mêmes tâches. Qu’est-ce que cela impliquait pour nos équipes ? Pour commencer, localiser un code spécifique ou trouver des bugs était à peu près aussi simple que pour Deckard de traquer des réplicants rebelles dans une ville dystopique surpeuplée.

La gestion de plusieurs dépôts avec des fonctionnalités redondantes ralentit les temps de réponse et épuise les ressources. Notre solution ? Nous réorganiser vers une structure monorepo modulaire. Pour reprendre les termes de Blade Runner, au lieu de traquer des réplicants à travers une ville tentaculaire, nous allions naviguer au sein d’une mégastructure unique où les projets sont organisés en modules et où les réplicants peuvent être recherchés.

Ce plan d’action nécessiterait l’implémentation de nouveaux outils dans notre stack, une nouvelle interface utilisateur et la gestion de grandes quantités de code existant. Si vous nous permettez de paraphraser, « L’homme a trouvé son égal »… et c’est désormais le problème de l’équipe d’ingénierie.

L’une des premières étapes de la configuration de notre nouvelle application a consisté à trouver un moyen de réutiliser autant que possible notre ancien système afin de ne pas avoir à tout reconstruire. Mais nous ne voulions pas continuer à supporter toutes nos anciennes dépendances obsolètes. Nous devions trouver une méthode pour empaqueter notre code existant sans qu’il ne soit rejeté par la nouvelle infrastructure.

Module Federation est un moyen de définir un morceau de code (notre ancienne application dans son ensemble, dans ce cas) comme un actif unique et importable qui peut soit être autonome, soit être configuré pour partager des actifs avec le consommateur. Module Federation a apporté une solution en nous permettant de rempaqueter le code existant afin qu’il puisse être exploité par la nouvelle plateforme, sans pour autant compromettre toutes les nouvelles fonctionnalités que nous avions prévues. La majeure partie de notre équipe de développement pouvait continuer à corriger des bugs et à mettre à jour notre ancienne base de code, et la nouvelle application en bénéficierait automatiquement !

Pour y parvenir, nous devions créer un middleware de routage déclaratif qui nous permettrait de diriger le trafic entre l’ancienne et la nouvelle application. Nous allons progressivement porter l’ancien code vers la nouvelle plateforme, mais d’ici là, cette solution de routage par page nous permettra de lancer de nouvelles fonctionnalités sans perdre de temps, et sans avoir à tout réécrire d’un coup. Comme nous avions déjà défini les règles, il serait plus facile de modifier et de maintenir le routage au sein de notre application.

Outre les composants de migration à grande échelle, nous devions également réfléchir à la migration et à l’adaptation des processus existants centrés sur des fonctionnalités qui devaient continuer à fonctionner de manière familière pour l’utilisateur dans la nouvelle application.

Jusqu’à présent, nous avons mis en lumière certains éléments globaux tels que le stockage et la gestion des ressources. Mais ce projet consistait en une refonte complète de l’application Mailgun, qui contenait déjà des processus fonctionnels destinés à la clientèle qu’il nous fallait soit protéger, soit améliorer.

Le processus d’inscription à l’application est un bon exemple de la façon dont nous avons dû évaluer les modèles actuels, collaborer entre les équipes et implémenter notre nouvelle stack. Lors du découpage d’un projet en vue d’une action, nous nous posons toujours quelques questions :

1. Comment déterminons-nous et planifions-nous actuellement les données ?

Stratégie : documenter la logique actuelle d’inscription et de création de compte pour le processus Mailgun existant. Cela nous aiderait à archiver nos anciens processus, mais aussi à analyser précisément comment nous allions modifier le système actuel pour jeter les bases de notre mise à jour.

2. Quelles sont les étapes pour passer de notre itération actuelle à l’état souhaité ?

Stratégie : une fois nos actions documentées et planifiées, nous devions améliorer notre base de connaissances. Nous nous sommes concentrés sur l’apprentissage des conventions et des capacités du framework React que nous utiliserions pour activer le rendu côté serveur et des fonctionnalités supplémentaires afin d’améliorer notre efficacité.

3. Quel travail est attendu de la part des autres équipes ?

Stratégie : concevoir l’interface utilisateur. Comme nous fusionnions effectivement deux produits autonomes en une suite de produits partageant une même infrastructure, nous devions concevoir l’interface utilisateur en même temps que nous apportions des modifications aux produits. Cela signifiait que la majorité des mises à jour seraient également des refontes graphiques.

Notre objectif principal était de distinguer nos produits (Mailgun et Mailgun Optimize) sans créer deux infrastructures distinctes pour les supporter. Vous pourriez vous demander pourquoi les séparer ? Pourquoi ne pas simplement fusionner les produits, ce serait plus facile, non ? Eh bien, pas vraiment. Nos produits ont des objectifs très spécifiques, et le fait qu’un utilisateur ou une utilisatrice en adopte un ne signifie pas qu’il faut tous les adopter. De plus, l’objectif ultime de cette refonte était de développer une infrastructure capable de supporter l’ajout de nouveaux produits à l’avenir, sans compromettre les fonctionnalités du backend ni compliquer la navigation du point de vue de notre base d’utilisateurs.

La solution ? Design. Cela impliquait de définir de nouvelles normes pour nos applications Mailgun et Mailgun Optimize en matière d’illustrations, de couleurs de marque et de formatage de texte. Il fallait également aligner l’équipe marketing sur la façon dont nous parlons de nos produits et de leur synergie.

Lorsque nous avons commencé à concevoir le processus de design, nous devions prendre en compte les zones partagées de l’application par rapport aux zones spécifiques. Des fonctionnalités telles que la facturation et le processus d’inscription seraient des espaces partagés, par opposition aux zones indépendantes de l’interface utilisateur qui serviraient nos produits individuels.

Nous avons commencé en 2021 par examiner la section de facturation et par nous concentrer sur la logique qui permettrait aux utilisateurs de disposer d’un seul compte de facturation prenant en charge la gestion et la personnalisation de plusieurs produits. Cela a donné le ton sur la façon dont nous allions avancer et analyser des fonctionnalités telles que la facturation ou notre processus d’inscription sous l’angle de la convergence de plusieurs produits.

Nous avons identifié l’ensemble des points de contact qui dépendraient soit d’un espace partagé, soit d’un espace spécifique aux produits au sein de l’application. Cela incluait des éléments tels qu’une navigation à gauche qui serait propre à chaque produit et intégrerait des paramètres spécifiques, tout en veillant à ce que les espaces partagés de l’application suivent les mêmes modèles.

Nous avons mené de nombreuses recherches sur la concurrence, mais aussi sur les tendances générales en matière de modèles de design, afin de voir comment le passage d’un produit à l’autre au sein d’une même application se faisait aujourd’hui et ce qui était pertinent pour la barre de navigation supérieure.

Nicki Snyder

Ensuite, nous avons examiné les éléments du parcours utilisateur afin de pouvoir cartographier la structure du design et les palettes de couleurs qui aideraient à optimiser l’expérience utilisateur. Deux questions nous ont guidés :

1. Quel parcours un utilisateur emprunterait-il désormais en naviguant dans une seule application au lieu de deux applications distinctes ?
2. Comment prévoyions-nous de gérer et d’ajuster le flux de design autour d’une fonctionnalité particulière au sein de la nouvelle application ?

Nous avons créé des designs qui variaient les couleurs et le placement pour diriger les utilisateurs vers des interactions au sein de l’application, puis nous avons effectué des tests utilisateurs pour observer et valider les parcours utilisateurs. Où les utilisateurs naviguaient-ils ? Que nous apprenaient les mouvements de leur souris sur leurs éventuelles hésitations ? Que s’attendaient-ils à voir ?

À partir de ces tests utilisateurs, nous avons pu affiner les éléments de design afin d’optimiser la navigation de manière intuitive pour nos utilisateurs. Ensuite, une expérience en version bêta a été lancée pour une sélection d’utilisateurs, ce qui nous a permis de recueillir des informations issues de sessions utilisateurs et d’instances réelles pour nous guider sur ce qui fonctionnait et ce qui devait encore être ajusté.

Le changement des ressources visuelles relevait pour moitié de la navigation et pour moitié de l’unification. Personnaliser les menus de navigation avec la palette de couleurs de notre marque peut sembler être un besoin purement esthétique, mais nous savions que nous étions en train de créer le thème qui permettrait à l’avenir de distinguer nos produits au sein d’un espace partagé.

Nous avons créé une structure de navigation évolutive non seulement pour Mailgun et Mailgun Optimize, mais aussi pour nos futurs produits d’email.

Nicki Snyder direction du design d’expérience produit

Les icônes de produits permettraient une reconnaissance de marque indépendante, sans créer la confusion que pourrait engendrer l’affichage des logos complets. Cela nous donnerait également l’occasion de développer la notoriété des autres produits de notre portefeuille en créant des liens vers eux à partir de leurs icônes. En ajoutant une zone Explorer au sein de l’application où les utilisateurs peuvent passer d’un produit à l’autre, nous pourrions favoriser les ventes croisées auprès des utilisateurs et faire connaître l’ensemble de notre suite de produits.

Et enfin, en tant qu’équipe, nous avons pensé qu’il serait vraiment génial d’avoir un nouveau look rafraîchissant pour accompagner cette nouvelle technologie afin d’amplifier l’impact de toutes nos nouvelles créations.

Les applications ne peuvent pas rester figées, et Portal évoluera au fil du temps. C’était tout l’intérêt de construire quelque chose avec une logique et une infrastructure conçues pour évoluer. Alors, quels sont les éléments qui devraient changer en premier ?

• Affiner l’architecture de déploiement : dans « 1re partie : d’excellentes idées », nous avons évoqué le volume de code que nous avons écrit au cours de la dernière décennie (des milliers de lignes), et tout comme il faudra du temps pour porter progressivement ce code, il faudra du temps pour mettre hors service nos anciens processus de déploiement. Cela signifiait que nous devions concevoir Portal pour qu’il fonctionne avec deux processus de déploiement, nos anciens processus et notre nouvelle compilation utilisant Cockpit, ce qui fut la tâche la plus facile au monde… C’était un vrai cauchemar, deux processus de déploiement ! Mais nous ne manquons pas d’ambition.
• Gérer plusieurs bases de code : à mesure que nous travaillons pour porter progressivement notre code, nous continuerons à devoir gérer plusieurs bases de code et à transférer le code de différents ensembles de produits avant de pouvoir tout unifier.

Portal est passé par les tests utilisateurs et la version bêta, nous avons donc pu détecter et corriger tous les bugs – phrase que l’équipe d’ingénierie n’a jamais prononcée.

La refonte de l’application a été réalisée pour servir nos utilisateurs tout en facilitant la vie de nos équipes en interne qui la gèrent. Nous intégrons donc les retours issus d’observations et de commentaires tant internes qu’externes. Nous sommes partis avec l’intention qu’aucun processus ne soit détérioré, et que la mise à jour de l’application ne priorise pas un processus au détriment de la qualité d’un autre. Et nous sommes convaincus que tout est aussi bien, voire mieux, que dans notre ancienne version.

Comment conclure un article alors que le projet est toujours en cours ? L’application Mailgun n’est sortie que récemment de sa version bêta et nous apportons régulièrement des améliorations mineures tout en planifiant des déploiements plus importants qui s’appuieront sur cette refonte initiale. Bill et Ted diraient de rester excellents les uns avec les autres et de continuer à faire la fête. En termes d’ingénierie, cela signifie que nous allons de l’avant et que nous itérons.

Ce projet marque une étape majeure dans la séparation visuelle de nos produits Mailgun et Mailgun Optimize au sein de notre application. Il marque également un tournant technologique et une nouvelle approche de notre développement front-end. Au-delà du simple aspect esthétique, nous avons mis l’accent sur les performances afin que nos versions restent petites et agiles. Les changements introduits par cette refonte sont le fruit d’un travail d’équipe exceptionnel qui nous permettra de nous affranchir de notre ancien monolithe front-end.

Nous n’aurions pas pu y parvenir sans l’aide de notre équipe incroyablement talentueuse, et nous ne voulions pas terminer cette série sans lui adresser nos remerciements particuliers.

• Équipe Core UI : Nando Peña, Matt Leong, Matthew Prestlien
• Équipe Growth : Keith Cruz, Ryan Little, Jorge Miramontes, Mazen Abdul
• Équipe Mailgun Optimize : David Ortiz, Dannon Gilbert, Jeffrey Jurgajtis, Peter Trinder
• Équipe Mailgun : Celeste Rance, Jonathan Kruse, Iqbal Singh, Levi Trejo, John Badali, Chris Farmer, Nicki Snyder (design)
• Sponsor exécutif : Josh Odom

Ce projet a commencé comme une initiative locale au sein de Mailgun et s’est développé pour susciter l’engouement de toutes les équipes. Aujourd’hui, notre application mise à jour offre des expériences de haut niveau pour les utilisateurs et une expérience améliorée pour l’équipe de développement. Mais nous n’avons pas terminé. Nous n’avons jamais terminé.

Vous souhaitez passer en coulisses et suivre nos aventures au fil de nos prochains déploiements ? Inscrivez-vous à notre newsletter pour ne rien manquer.

Auteur·trice: Nando Peña Nando Pena is a Software Developer IV at Sinch Mailgun. He is a front end developer focusing on our core UI technology and experiences. He writes to share stories and experiences about developer projects.