自律性と調整のバランスをとる

マイクロフロントエンドアーキテクチャは、チームの自律性に強く偏っています。ただし、問題を解決するための柔軟性をサポートできる分野と多様なアプローチを区別し、連携を実現するために標準化が必要な分野を区別することが重要です。シニアリーダーやアーキテクトは、マイクロフロントエンドのセキュリティ、パフォーマンス、運用上の優秀性、信頼性のバランスを取るために、これらの分野を早期に特定し、投資を優先する必要があります。このバランスを見つけるには、マイクロフロントエンドの作成、テスト、リリース、ログ記録、モニタリング、アラートが含まれます。

マイクロフロントエンドの作成

理想的には、エンドユーザーのパフォーマンスの観点からメリットを最大化するために、すべてのチームが強く連携しています。実際には、これは難しく、より多くの労力が必要になる場合があります。複数のチームがオープンで透明性のある議論を通じて貢献できる、いくつかの書面によるガイドラインから始めることをお勧めします。その後、チームは徐々に Cookiecutter ソフトウェアパターンを採用できます。これにより、プロジェクトを足場するための統一された方法を提供するツールの作成がサポートされます。

このアプローチを使用すると、意見や制約を和らげることができます。欠点は、これらのツールの作成とメンテナンスに多大な投資が必要であり、デベロッパーの生産性に影響を与えずにブロッカーに迅速に対処できることです。

マイクロフロントエンドの E nd-to-end テスト

ユニットテストは所有者に任せることができます。独自のシェルで実行されているマイクロフロントエンドをクロステストするための戦略を早期に実装することをお勧めします。この戦略には、本番リリースの前後にアプリケーションをテストする機能が含まれています。重要な機能を手動でテストするには、技術系および技術系以外の人向けのプロセスとドキュメントを作成することをお勧めします。

変更によって機能的なカスタマーエクスペリエンスや機能しないカスタマーエクスペリエンスが損なわれないようにすることが重要です。理想的な戦略は、主要な機能とセキュリティやパフォーマンスなどのアーキテクチャ特性の両方について、自動テストに徐々に投資することです。

マイクロフロントエンドのリリース

各チームには、コードをデプロイし、意見を交換して、独自のインフラストラクチャを構築するための独自の方法があるかもしれません。このようなシステムを維持するための複雑さのコストは、通常、抑止力です。代わりに、 に早期投資して、共有ツールで適用できる共有戦略を実装することをお勧めします。

選択した CI/CD プラットフォームを使用してテンプレートを開発します。その後、チームは事前に承認されたテンプレートと共有インフラストラクチャを使用して、変更を本番環境にリリースできます。これらのシステムでは、テストと統合の初期期間後に大幅な更新が必要になることはほとんどないため、この開発作業に早期に投資を開始できます。

ログ記録とモニタリング

各チームは、運用または分析の目的で追跡するビジネスメトリクスとシステムメトリクスを異なるものにすることができます。Cookiecutter ソフトウェアパターンは、ここでも適用できます。イベントの配信は抽象化でき、複数のマイクロフロントエンドが消費できるライブラリとして使用できます。柔軟性のバランスを取り、自律性を提供するには、カスタムメトリクスをログに記録し、カスタムダッシュボードまたはレポートを作成するためのツールを開発します。このレポートにより、製品所有者との緊密なコラボレーションが促進され、エンドユーザーのフィードバックループが短縮されます。

配信を標準化することで、複数のチームが協力してメトリクスを追跡できます。例えば、e コマースウェブサイトでは、「製品の詳細」マイクロフロントエンドから「カート」マイクロフロントエンド、「購入」マイクロフロントエンドまでのユーザージャーニーを追跡して、エンゲージメント、解約、問題を測定することができます。各マイクロフロントエンドが 1 つのライブラリを使用してイベントをログに記録する場合、このデータ全体を消費し、それを包括的に調べて、洞察力のある傾向を特定できます。

アラート

ログ記録やモニタリングと同様に、アラートはある程度の柔軟性のために、標準化の恩恵を受けます。チームが異なれば、機能的アラートと非機能的アラートの反応が異なる場合があります。ただし、すべてのチームが共有プラットフォームで収集および分析されたメトリクスに基づいてアラートを開始する統合方法を持っている場合、ビジネスはチーム間の問題を特定できます。この機能は、インシデント管理イベント中に便利です。例えば、アラートは次のように開始できます。

• 特定のブラウザバージョンでの JavaScript クライアント側の例外の数の増加

• 特定のしきい値にわたってレンダリングが大幅に低下するまでの時間

• 特定の API を使用する場合の 5xx ステータスコードの数の増加

システムの成熟度に応じて、次の表に示すように、インフラストラクチャのさまざまな部分で労力のバランスをとることができます。

導入	研究と開発	昇順	成熟度
マイクロフロントエンドを作成します。	学習内容を実験、文書化、共有する。	新しいマイクロフロントエンドを足場するためのツールに投資します。導入をエバンジェライズします。	足場用のツールを統合。導入をプッシュします。
マイクロフロントエンドをエンドツーエンドでテストします。	関連するすべてのマイクロフロントエンドを手動でテストするメカニズムを実装します。	セキュリティとパフォーマンスの自動テストのためのツールに投資します。機能フラグとサービス検出を調査します。	サービス検出、本番環境でのテスト、自動 end-to-end テストのためのツールを統合。
マイクロフロントエンドをリリースします。	共有 CI/CD インフラストラクチャと自動複数環境リリースに投資します。導入をエバンジェライズします。	CI/CD インフラストラクチャのツールを統合する 手動ロールバックメカニズムを実装します。導入をプッシュします。	システムおよびビジネスメトリクスとアラートに基づいて自動ロールバックを開始するメカニズムを作成します。
マイクロフロントエンドのパフォーマンスを確認します。	システムイベントとビジネスイベントの一貫したログ記録のために、共有モニタリングインフラストラクチャとライブラリに投資します。	モニタリングとアラートのためのツールを統合します。チーム間のダッシュボードを実装して、全般的な状態をモニタリングし、インシデント管理を改善します。	ログ記録スキーマを標準化します。コストに合わせて最適化します。複雑なビジネスメトリクスに基づいてアラートを実装します。