BrazeがRequireJSを廃止し、フロントエンド技術スタックを最新化した方法

公開: 2021-09-24

世界中の何千ものマーケターにとって、Brazeダッシュボードは彼らが物事を起こす場所です。 このインターフェースを最高の状態に保つための作業は、製品設計者からエンジニアまで、さまざまな人々によって行われています。 これらの最適化は、多くの場合、ユーザーインターフェイスに関するものですが、同じくらい頻繁に、ダッシュボードをサポートするテクノロジーに関するものです。

近年、この分野で最も重要な変化の1つは、RequireJSの廃止と、ダッシュボードのWebpackへの移行でした。これは、BrazeのシニアソフトウェアエンジニアであるAlexGuerraが主導した取り組みです このプロジェクトへのGuerraの重要な貢献、移行プロセスの詳細、およびその後の速度の向上により、ダッシュボードに関連するコーディングの問題の解決がどのように容易になったのかを見てみましょう。

ハックの日から移行まで:すべての始まり

言うのはおかしいですが、私はほとんど偶然にRequireJS非推奨プロジェクトに取り組んでしまいました。 私は約18か月間、Braze Engineeringのメッセージングおよび自動化チームに取り組んできました。このチームは、コア製品のバックエンドメッセージ送信パイプラインの最適化に重点を置いています。 ある時点で、私は別のチームメンバーにフロントエンドがどのように機能するかを尋ねました。彼はそれについて漠然とした考えを持っていましたが、正確な詳細については明確ではありませんでした。

それは私に興味をそそられました。 ダッシュボードがどのように機能するかを本当に理解したかったのです。 また、Brazeは、従業員が情熱的なプロジェクトを遂行できるハックデーを開催しているため、次のハックデーを利用して、フロントエンドコードをマッピングして文書化することで、ダッシュボードの詳細を調べることにしました。 同じ頃、BrazeダッシュボードチームはRequireJSからWebpackへの切り替えを検討していました。これは大きな仕事になると予想されていました。 しかし、調査の過程で、ダッシュボードチームがBrazeプラットフォームのフロントエンドをサポートするソフトウェアのアップグレードに関連する作業の一部を自動化するのに役立つと思う道が見え始めました。

しかし、私たちが何を変えようとしていたのか、そしてなぜ私がそれについてとても興奮したのかを完全に理解するには、RequireJSとWebpackの違いを理解する必要があります。

ブレイズダッシュボードの進化:RequireJSとWebpack

それで、とにかく、ブレイズダッシュボードは何ですか? 最も基本的なレベルでは、これは単一ページのJavaScriptアプリケーションです。 また、マーケティング担当者がBraze Webサイトにアクセスしてプラットフォームにログインすると、通常、バンドルされたバージョンのダッシュボードのコードによって、マーケティング担当者が受け取るWebビューに通知されます。 実稼働用に異種ファイルを収集するこのバンドルには、ダッシュボードがより効率的に機能するのに役立ついくつかの異なる最適化が適用されています。

  • 読み込みを高速化するための縮小

  • ダッシュボードをさまざまなWebブラウザに適応させる自動コード変更

  • フロントエンドコードを必要に応じてオンデマンドでロードできるようにするコード分割

Brazeでは、JavaScriptコードのアセットバンドルプロセスは、元々、Web用に設計されたJavaScriptファイルおよびモジュールローダーであるRequireJSによってサポートされていました。 しかし、時間の経過とともに、ダッシュボードのコードをバンドルする方法を進化させる必要があるというコンセンサスがBraze ProductandEngineering組織との間で高まりました。

最大の動機付けの要因は、ビルドプロセスをスピードアップする必要性でした。 開発者は通常、コードに加えた変更を検証するたびにビルドプロセスを実行して、調整がソフトウェアに期待どおりに影響を与えていることを確認する必要があります。 オープンソースのJavaScriptモジュールバンドラーであるWebpackが、これらの複雑なビルドをRequireJSよりも迅速かつ効果的に実行できることが明らかになった後、切り替えを行う時期が来たことがわかりました。

特に、変更を加えることには3つの重要な利点があると感じました。

1.統一されたコードベース

その時点で、ダッシュボードのフロントエンドは基本的に2つに分割され、半分はCoffeeScriptで記述され、RequireJSを使用して構築され、もう1つはJavaScriptとTypeScriptで記述され、Webpackで構築されました。 ご想像のとおり、分割全体でコードを共有することは問題であり、多くの場合、すべてを機能させるには非常に脆弱なハックが必要でした。 したがって、単一のプロセスへの移行に関連する作業を行うことの大きな利点の1つは、コードベースを真に統合し、最新化する絶好の機会を提供したことです。

2.より短いフィードバックサイクル

前述したように、このプロジェクトに関連する大きな優先事項の1つは、ダッシュボードで作業するエンジニアのフィードバックサイクルを短縮する方法を見つけることでした。 当時、フロントエンドコードに変更を加えた場合、RequireJSを使用したバンドルプロセスには平均3分かかり、場合によっては8分かかることもありました。 コードが正常に動作しているかどうかをエンジニアが確認するのを待たせるには、長い時間がかかります。 Webpackを使用すると、最初の起動時間は約90秒続きますが、追加の変更はすべて大幅に高速化できるため、エンジニアは時間を有効に活用してより多くの作業を行うことができます。

3.より効果的なトラブルシューティング

コードエラーを見つけて対処することは、エンジニアリングチームの作業の重要な部分です。 Brazeでは、Sentryと呼ばれる製品を使用しており、問題が本番ダッシュボードに表示されたときに問題の原因を整理して追跡するのに役立ちます。 ただし、そのコードはRequireJSでビルドされたCoffeeScriptであるため、コンパイルおよび縮小されると、「navigateToPill」などの関数の説明的な名前は「a」などに名前が変更されます。 つまり、1行目の列200,000の「a」にタイプエラーが表示されることを意味します。これにより、ご想像のとおり、そのエラーの原因を特定するのに多くの作業が必要になります。 一方、Webpackにはソースマップと呼ばれるツールがあり、チームはその縮小されたコードを取得して、特定の列と行をソースファイルにマップできます。 つまり、「navigateToPill」に特定の行でエラーが発生したというSentryレポートが表示され、問題をより迅速に解決しやすくなります。

移行プロセス:RequireJSからWebpackへの移行

RequireJSからWebpackに切り替える必要性は明らかでしたが、事業の規模は、プロセスに少なくとも1年かかり、達成するために多くの複雑さとエンジニアリング帯域幅を必要とすることを意味しました。 当時の考えは、コードベースをセクションごとに体系的に調べ、すべてを手動で移行する必要があるというものでした。これは非常に面倒でした。

私のブレークスルーは、それを言いたいのであれば、自動化されたプロセスを通じてBrazeダッシュボードのコードを一括で変更できるコードを記述できること、そしてこれらの変更をロールバックする必要がある場合はコードの変更を解除できることを認識したことです。早く。 私は、ハックデープロジェクトに続いて、それが機能することを示すために概念実証を行うことになり、それから、一種の情熱的なプロジェクトとして、暇なときにそれを続けました。

とは言うものの、BrazeDashboardチームのシニアソフトウェアエンジニアであるGregBeaverが関与するまで、事態は実際にはうまくいきませんでした。 彼は、私が概念実証の一部として作成したスクリプトを取得し、他のエンジニアと共有できるツールに組み込むことができました。 つまり、ダッシュボードに関連するコードに取り組んでいるすべてのエンジニアに、ダッシュボードの実行中に停止させることなく、RequireJSからWebpackに移行できるということです。 代わりに、ツールを使用して、作業中のコードを全体的な変更と自動的に同期させることができました。

ツールは非常に高速になり(実行に約2分しかかかりません)、非常にうまく機能したため、移行の準備をしているときに、RequireJSに関連する遅いビルドの回避策としてエンジニアに実際に活用してもらいました。 彼らはブランチをWebpackに変換し、必要な変更を加えてから、古いコードでコミットできるように変換し直しました。

この新しい機能を自由に使用できるようにした移行計画では、メインブランチでGregのツールを数週間毎晩実行し、そのブランチのQA環境で、何かが壊れていないかどうかを手動で確認できるようにしました。 すべてが良好に見えると確信したら、組織の他のメンバーに計画された更新について説明し、コードをRequireJSからWebpackに移行する方法を説明し、取得する前にいくつかの重要な考慮事項についてヘッドアップしました。進行中です。

私たちのアプローチのおかげで、1年以上かかると予想されていたプロジェクトは、たった3週間で完了しました。これは非常に素晴らしいことです。 さらに予想外だったのは、移行の影響でした。特に、Webpackでのビルドプロセスは通常約1秒しかかからず、各コードチェックに必要な時間が99%以上短縮されました。

ブレイズでは、ゲラのような個人が独自の視点と才能を最大限に活用できる環境の構築に取り組んでいます。 あなたは限界を押し広げ、何が可能かを再考しようとしている人ですか? 募集中のポジションの詳細についてはキャリアページをご覧ください。