プロンプトとコンテキスト
複数のチームが1つのリポジトリを共有しており、セキュリティ、決済、データディレクトリには明確な責任体制が必要です。例外やチームの変更を含め、CODEOWNERSとブランチ保護またはルールセットを組み合わせて、検出可能で強制力があり監査可能な承認プロセスをどのように構築できるか説明してください。
面接官が評価するポイント
- CODEOWNERSによる自動リクエストと、ブランチ保護によって強制される必須承認の区別。
- オーナーの書き込みアクセス権限、チームの可視性、ターゲットブランチ、ファイル配置場所の確認。
- CODEOWNERS自体の保護、フォーク、ドラフトPull Request、バイパス、および古い承認（stale approvals）の処理。
- カバレッジ、マージブロック、待機時間、監査ログによるガバナンスの測定。
行うべき明確化のための質問
- どのディレクトリがマージをブロックする必要があり、どれが通知のみでよいですか？緊急パスは存在しますか？
- オーナーは個人ですか、それともチームですか？可視性、書き込みアクセス権限、ローテーションはどのように維持されますか？
- どのブランチが保護されていますか？ルールセットと従来の保護の両方が存在しますか？また、バイパスできるのは誰ですか？
- CODEOWNERS自体、フォーク、ドラフトPR、古い承認、離脱するメンバーはどのように処理されますか？
30秒の回答フレームワーク
クリティカルなディレクトリを責任あるチームにマッピングし、CODEOWNERSをマッチングおよび通知レイヤーとして、ブランチ保護またはルールセットをマージブロックレイヤーとして扱います。オーナーの書き込み権限、チームの可視性、ベースブランチのファイルを確認し、CODEOWNERS自体を保護して、監査可能な緊急バイパスを定義します。シミュレートしたPull Requestで、追加・移動・削除されたファイルおよびフォークを網羅します。承認待ち時間、ブロック、バイパス、孤立パスを監視します。
ステップごとの詳細解説
1. オーナーシップの境界を定義する
1つのグローバルチームを割り当てるのではなく、リスクと変更頻度によってディレクトリを分割します。すべてのパターンにはプライマリオーナー、バックアップオーナー、レビュー日が必要です。マッチしないパスを定期的に検出します。
2. リクエストと強制を分離する
CODEOWNERSは所有するファイルが変更されたときに自動的にレビューをリクエストしますが、マージをブロックするのはブランチ保護またはルールセットにおける必須のコードオーナーレビューのみです。通知を強制と誤認しないよう、両方のレイヤーを個別にテストします。
3. 設定と例外を保護する
CODEOWNERSを保護された場所に配置し、オーナーを割り当てます。緊急修正には、最小権限のバイパス、理由の記録、マージ後レビューを採用し、ドラフトPull Request、フォーク、新しいプッシュ後に破棄される承認を考慮に入れます。
4. 安全に運用および移行する
強制する前に、マッチング、孤立パス、待機時間、誤検知によるブロックを測定するため、レポートモードから開始します。チームやリポジトリが変更された際は、権限、ルールセット、監査クエリをまとめて更新し、ロールバックプランを維持します。
模範回答
リポジトリをリスク別に分割し、バックアップオーナーを設定したCODEOWNERSを作成し、チームの可視性と書き込みアクセス権限を確認します。CODEOWNERSがマッチングと通知を処理し、ブランチ保護またはルールセットが実際のマージブロックを提供するため、シミュレートしたPull Requestで両方を検証します。CODEOWNERSファイル自体も保護され、オーナーが割り当てられます。緊急バイパスは最小権限とし、正当な理由を求め、事後にレビューします。レポートモードから開始して孤立パス、誤ブロック、待機時間を測定し、古い承認、バイパス、カバレッジを監視しながら段階的に強制を適用します。
よくある間違い
- CODEOWNERSの自動リクエストが常にマージをブロックすると思い込むこと。
- チームが可視化されており、書き込みアクセス権限を持っている必要がある点を見落とすこと。
- CODEOWNERS自体を保護せず、オーナーシップの変更を単独で可能にしてしまうこと。
- ベースブランチ、フォーク、ドラフト、または古い承認を無視すること。
- 緊急バイパス、事後レビュー、監査証跡を省略すること。
- 孤立パス、待機時間、誤ブロックを考慮せずに承認数だけを測定すること。
フォローアップの質問と回答
リストされたすべてのオーナーが承認する必要がありますか？
別のルールで指定されていない限り、通常は該当するオーナー1名の承認でコードオーナーレビューの条件を満たします。リスクの高いディレクトリに追加の複数者承認ルールが必要かどうかは、プロダクト設計で指定する必要があります。
なぜCODEOWNERS自体を保護するのですか？
保護しない場合、コントリビューターがオーナーシップのマッピングを変更してからクリティカルなコードを変更し、意図した境界を回避できてしまうためです。ファイルにオーナーを割り当ててレビューを必須にすることで、その経路を塞ぎます。
ローテーション関連のブロックを回避するにはどうすればよいですか？
個人ではなく可視化されたチームを使用し、バックアップと変更チェックを維持し、アクセス権が変更されたときに孤立パスを監査し、新しいルールが適用される前にリグレッション検証用のPull Requestを実行します。