Как Braze отказалась от RequireJS и модернизировала наш стек интерфейсных технологий

От Hack Day до миграции: как все начиналось

Забавно, но я почти случайно оказался в проекте по прекращению поддержки RequireJS. Около восемнадцати месяцев я работаю в команде Braze Engineering по обмену сообщениями и автоматизации, которая занималась оптимизацией внутреннего конвейера отправки сообщений для нашего основного продукта. В какой-то момент я спросил другого члена команды, как работает внешний интерфейс, и, хотя у него было смутное представление об этом, он не знал точных деталей.

Мне стало любопытно; Мне очень хотелось понять, как работает наш дашборд. И поскольку Braze проводит дни взлома, которые позволяют сотрудникам заниматься любимыми проектами, я решил воспользоваться следующим днем ​​взлома, чтобы изучить все тонкости нашей панели инструментов, наметив и задокументировав интерфейсный код. Примерно в это же время команда панели инструментов Braze рассматривала возможность перехода с RequireJS на Webpack, что, как ожидалось, станет серьезным мероприятием. Но в ходе моего исследования я начал видеть путь вперед, который, как я думал, мог бы помочь команде приборной панели автоматизировать часть работы, связанной с обновлением программного обеспечения, поддерживающего внешний интерфейс платформы Braze.

Но чтобы получить полное представление о том, что мы хотели изменить и почему я так воодушевлен этим, вы должны понимать различия между RequireJS и Webpack.

Развитие информационной панели Braze: RequireJS против Webpack

Итак, что же такое приборная панель Braze? На самом базовом уровне это одностраничное приложение JavaScript. И когда маркетолог посещает веб-сайт Braze и входит в нашу платформу, веб-представление, которое он получает, обычно информируется связанной версией кода панели инструментов. В этом пакете, который собирает разрозненные файлы для производства, к ним применяется несколько различных оптимизаций, которые помогают панели управления работать более эффективно, в том числе:

• Минификация для ускорения загрузки.

• Автоматические модификации кода, позволяющие панели управления адаптироваться к различным веб-браузерам.

• Разделение кода, позволяющее загружать интерфейсный код по мере необходимости.

В Braze этот процесс объединения активов для нашего кода JavaScript изначально поддерживался RequireJS, загрузчиком файлов и модулей JavaScript, разработанным для использования в Интернете. Но со временем отдел продуктов и инженерии Braze пришел к единому мнению, что нам необходимо усовершенствовать способ связывания кода для приборной панели.

Самым большим мотивирующим фактором была необходимость ускорить процесс сборки. Обычно разработчику необходимо проходить процесс сборки каждый раз, когда он хочет проверить изменения, внесенные им в часть кода, чтобы убедиться, что их корректировка влияет на программное обеспечение так, как он ожидает. Как только стало ясно, что Webpack — сборщик модулей JavaScript с открытым исходным кодом — может выполнять эти сложные сборки быстрее и эффективнее, чем RequireJS, мы поняли, что пришло время переключиться.

В частности, мы чувствовали, что внесение изменений будет иметь три ключевых преимущества:

1. Единая кодовая база

На тот момент передняя часть панели инструментов была по существу разделена на две части: одна половина была написана на CoffeeScript и построена с использованием RequireJS, а другая — на JavaScript и TypeScript и построена с помощью Webpack. Как и следовало ожидать, совместное использование кода через границу было проблемой, и во многих случаях требовалось несколько очень хрупких хаков, чтобы все это заработало. Таким образом, одним из основных преимуществ выполнения работы, связанной с переходом на единый процесс, было то, что он предоставил прекрасную возможность по-настоящему унифицировать — и модернизировать — кодовую базу.

2. Более короткие циклы обратной связи

Как я упоминал выше, одним из главных приоритетов, связанных с этим проектом, был поиск способов сократить цикл обратной связи для инженеров, работающих над приборной панелью. В то время, если вы вносили изменения во внешний код, процесс связывания с RequireJS занимал в среднем три минуты, а иногда мог длиться и восемь минут. Это слишком много времени, чтобы заставить инженера ждать, чтобы узнать, нормально ли работает его код. С Webpack начальное время запуска составляет около 90 секунд, но каждое дополнительное изменение может быть выполнено значительно быстрее, что позволяет инженерам лучше использовать свое время и делать больше.

3. Более эффективное устранение неполадок

Поиск и устранение ошибок в коде — неотъемлемая часть работы любой инженерной группы. В Braze мы используем продукт под названием Sentry, который помогает систематизировать и отслеживать источник проблем, когда они появляются на рабочей панели. Но поскольку этот код был создан на CoffeeScript с помощью RequireJS, при его компиляции и минимизации описательное имя функции, такое как «navigateToPill», будет переименовано в что-то вроде «a». Это, в свою очередь, означало, что мы увидим ошибку типа в «а» в первой строке столбца 200 000, что, как вы понимаете, потребовало много работы, чтобы определить источник этой ошибки. Webpack, с другой стороны, имеет инструмент под названием Source Maps, который позволяет командам брать этот минимизированный код и сопоставлять заданный столбец и строку с исходным файлом; это означает, что вы будете получать отчеты Sentry, в которых говорится, что «navigateToPill» содержит ошибку в определенной строке, что упрощает и ускоряет решение проблем.

Процесс миграции: переход с RequireJS на Webpack

Необходимость перехода с RequireJS на Webpack была очевидна, но масштаб мероприятия означал, что они ожидали, что этот процесс займет не менее года и потребует больших усилий и инженерной пропускной способности. В то время считалось, что нам придется систематически просматривать кодовую базу раздел за разделом и вручную все мигрировать, что было бы очень обременительно.

Моим прорывом, если вы хотите это назвать, стало осознание того, что я могу написать код, способный массово изменять код панели управления Braze с помощью автоматизированного процесса, а также не изменять наш код, если нам нужно откатить эти изменения. быстро. Я закончил тем, что сделал доказательство концепции после моего проекта дня взлома, просто чтобы показать, что он может работать, а затем продолжил работать над ним в свободное время как своего рода проект страсти.

Тем не менее, дела по-настоящему не шли, пока не вмешался Грег Бивер, старший инженер-программист в команде Braze Dashboard. Он смог взять сценарии, которые я написал как часть проверки концепции, и включить их в инструмент, которым мы могли поделиться с другими инженерами. Это, в свою очередь, означало, что мы могли перейти с RequireJS на Webpack, не заставляя всех инженеров, работающих над кодом, связанным с приборной панелью, останавливаться, пока мы это делали; вместо этого они могли использовать инструмент для автоматической синхронизации любого кода, над которым они работали, с общими изменениями.

Инструмент оказался настолько быстрым — его запуск занимает всего около двух минут — и работал так хорошо, что, пока мы готовились к миграции, у нас был инженер, который использовал его как обходной путь для медленных сборок, связанных с RequireJS. Они просто преобразовали свою ветку в Webpack, внесли необходимые изменения, а затем преобразовали их обратно, чтобы они могли зафиксировать их в старом коде.

Имея в своем распоряжении эту новую возможность, наш план миграции заключался в том, чтобы запускать инструмент Грега в нашей основной ветке каждую ночь в течение нескольких недель и заставлять людей вручную проверять в среде контроля качества этой ветки, просто чтобы посмотреть, не сломалось ли что-нибудь. Как только мы убедились, что все выглядит хорошо, мы проинформировали остальную часть организации о запланированном обновлении, рассказали им, как они могут перенести свой код с RequireJS на Webpack, и предупредили их о нескольких ключевых соображениях, прежде чем они получили в стадии реализации.

Благодаря нашему подходу проект, который, как ожидалось, займет больше года, был завершен всего за три недели, что довольно невероятно. Еще более неожиданным было влияние миграции — в частности, процесс сборки в Webpack теперь обычно занимает всего около секунды, что сокращает время, необходимое для каждой проверки кода, более чем на 99%.

В Braze мы стремимся создать среду, в которой такие люди, как Гуэрра, могут максимально использовать свои уникальные взгляды и таланты. Вы тот, кто хочет раздвинуть границы и переосмыслить то, что возможно? Посетите нашу страницу вакансий, чтобы узнать больше о наших открытых вакансиях.