Comment Braze a abandonné RequireJS et a modernisé notre pile technologique frontale

Du Hack Day à la migration : comment tout a commencé

C'est drôle à dire, mais j'ai fini par travailler sur le projet de dépréciation RequireJS presque par accident. Je travaille dans l'équipe de messagerie et d'automatisation de Braze Engineering depuis environ dix-huit mois, une équipe axée sur l'optimisation du pipeline d'envoi de messages back-end pour notre produit principal. À un moment donné, j'ai demandé à un autre membre de l'équipe comment fonctionnait le front-end - et bien qu'il en ait une vague idée, il n'était pas clair sur les détails exacts.

Cela m'a rendu curieux; Je voulais vraiment comprendre comment fonctionnait notre tableau de bord. Et parce que Braze organise des journées de hack qui permettent aux employés de poursuivre des projets passionnants, j'ai décidé de profiter de la prochaine journée de hack pour explorer les tenants et les aboutissants de notre tableau de bord en cartographiant et en documentant le code frontal. À peu près à la même époque, l'équipe du tableau de bord Braze envisageait de passer de RequireJS à Webpack, ce qui devait être une entreprise majeure. Mais au cours de mon exploration, j'ai commencé à voir une voie à suivre qui, selon moi, pourrait aider l'équipe du tableau de bord à automatiser une partie du travail impliqué dans la mise à niveau du logiciel prenant en charge le frontal de la plate-forme Braze.

Mais pour avoir une image complète de ce que nous cherchions à changer et pourquoi cela m'a tellement enthousiasmé, vous devez comprendre les différences entre RequireJS et Webpack.

Faire évoluer le tableau de bord Braze : RequireJS vs Webpack

Alors, qu'est-ce que le tableau de bord Braze, de toute façon ? Au niveau le plus élémentaire, il s'agit d'une application JavaScript d'une seule page. Et lorsqu'un spécialiste du marketing visite le site Web de Braze et se connecte à notre plate-forme, la vue Web qu'il reçoit est généralement informée par une version groupée du code du tableau de bord. Ce bundle, qui collecte des fichiers disparates pour la production, comporte plusieurs optimisations différentes qui permettent au tableau de bord de fonctionner plus efficacement, notamment :

• Minification pour lui permettre de se charger plus rapidement

• Modifications automatiques du code permettant au tableau de bord de s'adapter aux différents navigateurs Web

• Fractionnement du code pour permettre au code frontal de se charger à la demande selon les besoins

Chez Braze, ce processus de regroupement d'actifs pour notre code JavaScript était initialement pris en charge par RequireJS, un chargeur de fichiers et de modules JavaScript conçu pour une utilisation Web. Mais au fil du temps, un consensus s'est développé avec l'organisation Braze Product and Engineering sur le fait que nous devions faire évoluer la façon dont nous regroupions le code pour le tableau de bord.

Le plus grand facteur de motivation était la nécessité d'accélérer le processus de construction. Un développeur doit généralement passer par le processus de construction chaque fois qu'il souhaite valider les modifications qu'il a apportées à un morceau de code, pour s'assurer que leur ajustement a un impact sur le logiciel comme prévu. Une fois qu'il était clair que Webpack, un bundle de modules JavaScript open source, pouvait réaliser ces constructions compliquées plus rapidement et plus efficacement que RequireJS, nous savions qu'il était temps de faire le changement.

En particulier, nous avons estimé que le changement aurait trois avantages clés :

1. Une base de code unifiée

À ce stade, le front-end du tableau de bord était essentiellement divisé en deux, une moitié étant écrite en CoffeeScript et construite à l'aide de RequireJS, tandis que l'autre était écrite en JavaScript et TypeScript et construite avec Webpack. Comme vous vous en doutez, le partage de code à travers la division était un problème et dans de nombreux cas, il a fallu des hacks très fragiles pour que tout fonctionne. Ainsi, l'un des principaux avantages de faire le travail impliqué dans la migration vers un processus unique était qu'il présentait une occasion en or d'unifier véritablement et de moderniser la base de code.

2. Cycles de rétroaction plus courts

Comme je l'ai mentionné ci-dessus, l'une des grandes priorités associées à ce projet était de trouver des moyens de raccourcir le cycle de rétroaction pour les ingénieurs travaillant sur le tableau de bord. À l'époque, si vous apportiez une modification au code frontal, le processus de regroupement avec RequireJS prenait en moyenne trois minutes, et parfois jusqu'à huit minutes. C'est long à faire attendre un ingénieur pour savoir si son code fonctionne normalement. Avec Webpack, le temps de démarrage initial dure environ 90 secondes, mais chaque modification supplémentaire peut être effectuée beaucoup plus rapidement, ce qui permet aux ingénieurs de mieux utiliser leur temps et d'en faire plus.

3. Dépannage plus efficace

La recherche et le traitement des erreurs de code constituent une partie essentielle du travail de toute équipe d'ingénierie. Chez Braze, nous utilisons un produit appelé Sentry qui permet d'organiser et de retracer la source des problèmes lorsqu'ils apparaissent dans le tableau de bord de production. Mais parce que ce code était CoffeeScript construit avec RequireJS, lorsqu'il était compilé et minifié, le nom descriptif d'une fonction comme "navigateToPill" serait renommé en quelque chose comme "a". Cela, à son tour, signifiait que nous verrions une erreur de type dans "a" sur la première ligne, colonne 200 000, ce qui, comme vous l'imaginez, a demandé beaucoup de travail pour déterminer la source de cette erreur. Webpack, d'autre part, dispose d'un outil appelé Source Maps qui permet aux équipes de prendre ce code minifié et de mapper une colonne et une ligne données au fichier source ; cela signifie que vous obtiendrez des rapports Sentry indiquant que "navigateToPill" a eu une erreur sur une ligne spécifique, ce qui facilite la résolution des problèmes plus rapidement.

Le processus de migration : passer de RequireJS à Webpack

La nécessité de passer de RequireJS à Webpack était claire, mais l'ampleur de l'entreprise signifiait qu'ils s'attendaient à ce que le processus prenne au moins un an et implique beaucoup de complexité et de bande passante d'ingénierie à réaliser. L'idée à l'époque était qu'il fallait systématiquement parcourir la base de code section par section et tout migrer manuellement, ce qui aurait été vraiment onéreux.

Ma percée, si vous voulez l'appeler ainsi, a été de réaliser que je pouvais écrire du code capable de modifier le code du tableau de bord Braze en masse grâce à un processus automatisé - et également de ne pas modifier notre code, si nous devions annuler ces modifications. rapidement. J'ai fini par faire une preuve de concept suite à mon projet hack day, juste pour montrer que ça pouvait marcher, puis j'ai continué à travailler dessus pendant mon temps libre comme une sorte de projet passionnel.

Cela dit, les choses n'ont pas vraiment décollé jusqu'à ce que Greg Beaver, ingénieur logiciel senior au sein de l'équipe Braze Dashboard, s'implique. Il a pu prendre les scripts que j'avais écrits dans le cadre de ma preuve de concept et les incorporer dans un outil que nous pourrions partager avec d'autres ingénieurs. Cela, à son tour, signifiait que nous pouvions migrer de RequireJS vers Webpack sans forcer tous les ingénieurs travaillant sur le code lié au tableau de bord à s'arrêter pendant que nous le faisions ; au lieu de cela, ils ont pu utiliser l'outil pour synchroniser automatiquement tout code sur lequel ils travaillaient avec les modifications globales.

L'outil a fini par être si rapide (il ne prend que deux minutes environ à exécuter) et a si bien fonctionné que pendant que nous préparions les migrations, un ingénieur l'a utilisé comme solution de contournement pour les builds lents associés à RequireJS. Ils viennent de convertir leur branche en Webpack, ont apporté les modifications nécessaires, puis l'ont reconvertie afin de pouvoir la valider dans l'ancien code.

Avec cette nouvelle capacité à notre disposition, notre plan de migration était d'exécuter l'outil de Greg sur notre branche principale tous les soirs pendant quelques semaines et de demander aux gens de l'examiner manuellement dans l'environnement QA de cette branche, juste pour voir si quelque chose était cassé. Une fois que nous étions convaincus que tout semblait bon, nous avons informé le reste de l'organisation de la mise à jour prévue, leur avons expliqué comment ils pouvaient migrer leur code de RequireJS vers Webpack, et leur avons donné un aperçu de quelques considérations clés avant qu'ils ne deviennent en cours.

Grâce à notre approche, un projet qui devait durer plus d'un an s'est terminé en seulement trois semaines, ce qui est assez incroyable. L'impact de la migration était encore plus inattendu. En particulier, le processus de génération sur Webpack ne prend désormais généralement qu'environ une seconde, ce qui réduit de plus de 99 % le temps nécessaire à chaque vérification de code.

Chez Braze, nous nous engageons à créer un environnement où des individus comme Guerra peuvent tirer le meilleur parti de leurs perspectives et talents uniques. Êtes-vous quelqu'un qui cherche à repousser les limites et à réinventer ce qui est possible ? Consultez notre page carrières pour en savoir plus sur nos postes vacants.