モジュラーモノリス ADR 003: モジュールのスチュワードシップ
コンテキスト
ドメインとプラットフォーム層にスチュワードシップをどのように割り当てるか？コードのその部分に対してビジョンと方向性を提供できる明示的なスチュワードがいない共有コードが大量に存在します。
決定事項
私たちは オーナー（owners） の代わりに スチュワード（stewards） という用語を使用することで、GitLab の原則である everyone can contribute により沿うようにします。スチュワードはコードの世話役です。特定の機能がどのように設計され、なぜそうなっているかを理解しています。アーキテクチャ上の特性と制約も理解しています。ただし、変更を歓迎し、コントリビューターが成功できるよう導きます。
ドメインのバウンデッドコンテキスト由来かプラットフォーム層由来かにかかわらず、モジュールには少なくとも 1 つのスチュワードグループが必要です。このグループはチーム名（または GitLab グループハンドル）にできます。オプションで、スチュワードのリストには個人の IC エントリを含めることができます。
モジュールのコード構造上の仕組み（Packwerk パッケージや gem など）はまだ決定していません。その決定が行われるまで、既存の CODEOWNERS ファイルを使い、モジュールのディレクトリを 1 つ以上のグループ（および任意で個人 IC）に割り当てることでスチュワードシップを示します:
/ci/ @gitlab-org/maintainers/pipeline-execution @gitlab-org/maintainers/pipeline-authoring @grzesiek @ayufan
後でメタデータを持つコード構造の仕組み（Packwerk の package.yml や gemspec など）を採用した場合は、スチュワードシップをそのメタデータへ移し、関連する CODEOWNERS セクションをそこから生成できます。
プラットフォーム層から抽出された gem（例: Gitlab::Redis）にも、スチュワードを割り当てるべきです。
結果
コード上で定義されたスチュワードシップは非常に強力な効果をもたらします:
- Review Roulette や Suggested Reviews 機能は、
CODEOWNERSを使ってレビューをスチュワードへルーティングします。 - エンジニアはスチュワードを簡単に特定し、早期に設計の議論ができます。
代替案
CODEOWNERS を使用する代わりに、各チームが自分たちの責任範囲であるバウンデッドコンテキストを非公式に把握していることに依存し、スチュワードシップをどこにも記録しない方法があります。プラットフォームモジュール内の「共有コード」については、メンテナーがスチュワードの役割を担うことを期待します。
- メリット: トレーニーメンテナーに明確な開発パスと目標を与えられます。現状では、成功したメンテナーになるために何を習得すべきかが不明確に感じられます。
- デメリット: 「共有」コードの量は非常に多く、特定の機能について誰が最もよく知っているかを理解するのは依然として困難です。明示的な記録がなければ、スチュワードシップは暗黙知のままです。新しいコントリビューターやエージェントからは見えず、それはまさにモジュール化が取り除こうとしているものです。
c955a93f)