組織と作業方法 - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

組織と作業方法

すべてのアーキテクチャ戦略と同様に、マイクロフロントエンドは、組織が実装することを選択するテクノロジーよりもはるかに大きな意味を持ちます。マイクロフロントエンドアプリケーションを構築する決定は、ビジネス、製品、組織、運用、さらには文化 (チームの権限付与や意思決定の分散など) と一致する必要があります。その代わりに、このタイプのマイクロフロントエンドアーキテクチャは、真の俊敏性、製品主導の開発をサポートします。これは、そうでなければ独立したチーム間の通信オーバーヘッドを大幅に削減するためです。

アジャイル開発

アジャイルソフトウェア開発の概念は、ここ数年で非常に一般的になり、事実上すべての組織がアジャイルに取り組むと主張しています。アジャイルの決定的な定義はこの戦略の範囲外ですが、マイクロフロントエンド開発に関連する主要な要素を確認する価値があります。

アジャイルパラダイムの基盤はアジャイルマニフェスト (2001) です。このマニフェストは、4 つの主要な原則 (「プロセスやツールに対する個人とインタラクション」など) と 12 の原則を仮定しています。Scrum や Scaled Agile Framework (SAFe ) などのプロセスフレームワークがアジャイルマニフェストを中心に出現し、日常的なプラクティスへの道を見つけました。ただし、その背後にある哲学は、ほとんど誤解または無視されます。

マイクロフロントエンドアーキテクチャでは、以下のアジャイル原則を採用することが重要です。

  • 「作業ソフトウェアを数週間から数か月まで頻繁に配信し、より短いタイムスケールを優先します。」

    この原則は、段階的に作業し、ソフトウェアを可能な限り定期的に本番環境に配信することの重要性を強調しています。技術的な観点から見ると、これは継続的インテグレーションと継続的デリバリー (CI/CD) を指します。CI/CD では、構築、テスト、デプロイのためのツールとプロセスは、各ソフトウェアプロジェクトに不可欠な要素です。また、プリンシパルは、ランタイムインフラストラクチャと運用上の責任がチームによって所有されている必要があることも意味します。この所有権は、独立したサブシステムがインフラストラクチャと運用の要件を大幅に異なる可能性がある分散システムでは特に重要です。

  • 「動機のある個人を中心にプロジェクトを構築します。必要な環境とサポートを提供し、それらを信頼してジョブを完了させます。」

    「最高のアーキテクチャ、要件、設計は自己組織チームから生まれます」

    これらの原則はどちらも、所有権、独立性、 end-to-end 責任の利点を強調しています。マイクロフロントエンドアーキテクチャは、チームがマイクロフロントエンドを真に所有している場合 (および唯一の場合) に成功します。構想から設計、実装、デリバリー、運用まで、E nd-to-endの責任により、チームは実際に所有権を行使できます。この独立性は、チームが戦略的方向性を自律させるために、技術的にも組織的にも必要です。ウォーターフォール開発モデルを使用する一元化された組織では、マイクロフロントエンドプラットフォームを使用することはお勧めしません。

チームの構成と規模

ソフトウェアチームが所有権を行使するには、組織が課す境界内で、チームが提供する方法と内容を含め、自らを管理する必要があります。

効果的に機能するためには、チームはソフトウェアを個別に配信でき、配信する最善の方法を決定する権限を持っている必要があります。これらのアイテムの計画に関与せずに、外部製品マネージャーまたは外部デザイナーから UI 設計から機能要件を受け取るチームは、自律型と見なすことはできません。この機能が既存の契約や機能に違反する可能性があります。このような違反には、さらなる議論と交渉が必要であり、配信が遅れたり、チーム間で不要な競合が発生したりするリスクがあります。

同時に、チームが大きすぎないようにする必要があります。大規模なチームにはより多くのリソースがあり、個々の欠席に対応できますが、コミュニケーションの複雑さは新しいメンバーごとに指数関数的に増加します。ユニバーサルに有効な最大チームサイズを記述することはできません。プロジェクトに必要な人数は、チームの成熟度、技術的複雑さ、イノベーションのペース、インフラストラクチャなどの要因によって異なります。例えば、Amazon は 2 つのピザのルールに従います。2 つのピザを食べるには大きすぎるチームは、小さなチームに分割する必要があります。これは課題になる可能性があります。分割は自然の境界に沿って行われ、各チームに作業に対する自律性と所有権を与える必要があります。

DevOps 文化

DevOps は、開発ライフサイクルのステップが組織的および技術的な観点から緊密に統合されているソフトウェアエンジニアリングのプラクティスを指します。一般的な考え方とは対照的に、文化と考え方には DevOps あまり関係なく、役割とツールにもほとんど関係ありません。

従来、ソフトウェア組織には、設計、実装、テスト、デプロイ、運用などのスペシャリストチームがありました。チームがジョブを完了するたびに、プロジェクトは次のチームに引き渡されます。ただし、サイロ化された専門チームを通じてソフトウェアを配信すると、引き継ぎ中に摩擦が発生します。同時に、スペシャリストが狭い焦点で作業を強制されると、隣接するドメインに関する知識が不足し、製品の体系的なビューがありません。これらの障害により、ソフトウェア製品の一貫性が低下する可能性があります。

例えば、ソフトウェアアーキテクトが別のチームの誰かが実装するソリューションを設計すると、実装の固有の側面 (依存関係の不一致など) が見落とされる可能性があります。その後、開発者 back-and-forth はショートカット (猿のパッチなど) を使用するか、アーキテクトと開発チームの間で形式化された が開始されます。これらのプロセスを管理するオーバーヘッドにより、開発は (柔軟、適応的、段階的、非公式な意味で) アジャイルではなくなりました。

この用語 DevOps は主に文化に関連していますが、実際に DevOps 実現するテクノロジーとプロセスを意味します。 DevOps は CI/CD と密接に関連しています。デベロッパーは、ソフトウェアの増分の実装を完了すると、Git などのバージョン管理システムにコミットします。従来、ビルドシステムはソフトウェアを構築して統合し、多かれ少なかれ統合され一元化されたプロセスでテストしてリリースしていました。CI/CD では、ソフトウェアの構築、統合、テスト、およびリリースは本質的に自動化されています。理想的には、このプロセスは、特定のプロジェクトに特に合わせた設定ファイルを通じてソフトウェアプロジェクト自体の一部です。

可能な限り多くのステップが自動化されます。例えば、ほぼすべてのタイプのテストを自動化できるため、手動テストのプラクティスを減らす必要があります。このようにプロジェクトを設定すると、ソフトウェア製品の更新を 1 日に数回、高い信頼性で配信できます。がサポートするもう 1 つのテクノロジー DevOps は、Infrastructure as Code (IaC) です。

従来、IT インフラストラクチャをセットアップして維持するには、ハードウェア (データセンターでケーブルとサーバーをセットアップする) と運用ソフトウェアのインストールと保守を手動で行う必要があります。これは必要でしたが、多くの欠点がありました。セットアップに時間がかかり、エラーが発生しやすくなります。ハードウェアが過剰にプロビジョニングされたり、プロビジョニングが不足したりすることがよくあり、過剰な支出やパフォーマンスの低下につながります。IaC を使用すると、クラウドサービスを自動的にデプロイして更新できる設定ファイルを通じて IT システムのインフラストラクチャ要件を記述できます。

これらすべてがマイクロフロントエンドとどのような関係がありますか? DevOps、CI/CD、IaC は、マイクロフロントエンドアーキテクチャを補完するのに理想的です。マイクロフロントエンドの利点は、高速でスムーズな配信プロセスに依存しています。 DevOps 文化は、チームが end-to-end 責任を持ってソフトウェアプロジェクトを所有する環境でのみ存続できます。

複数のチームにわたるマイクロフロントエンド開発のオーケストレーション

複数の部門横断的なチームにマイクロフロントエンド開発をスケーリングすると、2 つの問題が発生します。まず、チームはパラダイムの独自の解釈を開発し、フレームワークとライブラリの選択を行い、独自のツールとヘルパーライブラリを作成します。次に、完全自律型チームは、低レベルのインフラストラクチャ管理などの一般的な機能に責任を負う必要があります。したがって、マルチチームマイクロフロントエンド組織に 2 つのチーム、つまり有効化チームとプラットフォームチームを導入することは理にかなっています。これらの概念は、分散システムを使用する最新の IT 組織で広く採用されており、チームトポロジー で十分に文書化されています。

次の図は、3 つのマイクロフロントエンドチームにツール、ライブラリ、標準、テストを提供する有効化チームを示しています。プラットフォームチームは、これら 3 つのマイクロフロントエンドチームにインフラストラクチャ、共有ランタイム機能、ドメインサービスを提供します。

3 つのマイクロフロントエンドチームに貢献している有効化チームとプラットフォームチーム。

プラットフォームチームは、マイクロフロントエンドチームを未分化の重労働から解放することでサポートします。このサポートには、コンテナランタイム、CI/CD パイプライン、コラボレーションツール、モニタリングなどのインフラストラクチャサービスが含まれます。ただし、プラットフォームチームを設定すると、開発がオペレーションからデタッチされる組織につながるべきではありません。逆の場合、プラットフォームチームはエンジニアリング製品を提供し、マイクロフロントエンドチームはプラットフォーム上のサービスの所有権とランタイム責任を負います。

有効化チームは、ガバナンスに重点を置き、マイクロフロントエンドチーム全体の一貫性を確保することでサポートを提供します。(プラットフォームチームはこれに関与しないでください)。有効化チームは UI ライブラリなどの共有リソースを維持し、フレームワークの選択、パフォーマンス予算、相互運用性規則などの標準を作成します。同時に、ガバナンスで定義されている標準とツールの適用に関するトレーニングを新しいチームまたはチームメンバーに提供します。

デプロイ

マイクロフロントエンドチームの自律性の北極星は、他のマイクロフロントエンドチームから独立した本番稼働への道筋を持つ自動パイプラインを持つことです。共有なしの原則に従うチームは、独立したパイプラインを実装できます。ライブラリを共有したり、プラットフォームチームに依存するチームは、デプロイパイプラインの依存関係を管理する方法を決定する必要があります。

通常、各パイプラインは次の処理を行います。

  • フロントエンドアセットを構築

  • 消費のためにアセットをホスティングにデプロイします

  • 新しいバージョンを顧客に配信できるように、レジストリとキャッシュが更新されていることを確認します

実際のパイプラインステップは、テクノロジースタックとページ構成アプローチによって異なります。

クライアント側の構成では、アプリケーションバンドルをホスティングバケットにアップロードし、CDN でのキャッシュを通じて消費にリリースすることを意味します。サービスワーカーでブラウザキャッシュを使用するアプリケーションでは、サービスワーカーキャッシュを更新する方法も実装する必要があります。

サーバー側の構成では、通常、サーバーコンポーネントの新しいバージョンをデプロイし、新しいバージョンを検出できるようにマイクロフロントエンドレジストリを更新することを意味します。Blue/Green または Canary のデプロイパターンを使用して、新しいバージョンを徐々にロールアウトできます。