概要

前提として元々 PolyRepo を採用していた組織で生成AIの利用にあたって1システムのコードを MonoRepo にしたいという要望があり GitHub レポジトリの設定を見直す話になりました。

元々 PolyRepo だった理由は特になかったのですが、MonoRepo 化を進めていくにあたってチームによって考慮されていない事が出てきました。この話については別の日に書きます。

今回は

CODEOWNERS
Rulesets (旧・Branch Protection Rulesets からの移行を含む)
Templates

について記載します。

なお、前提となる GitHub は Enterprise Cloud プランを利用しています。

CODEOWNERS

機能概要

名前の通り、コード群に対するオーナーシップを持っている人を指定する設定ファイルです。このファイルを元に GitHub レポジトリの他の制約・権限設定も実施します。

見直しポイント

新規導入しました。これまで PolyRepo だったので、レポジトリ単位で管理チームや管理者が分かれていました。他チームはあっても Read 権限だけ (要望はGitHub外のタスク管理システムで挙げてもらってます)でした。そのため、レポジトリ内部の権限設定はあまり需要がない状態でした。

しかし、次期のレポジトリ構成ではディレクトリの第一階層で権限が分かれます。そうした場合、Rulesets などで権限制約をかけるために CODEOWNERS を使うことになりました。

どういった設定に利用したかは Rulesets の方に記載します。

配置場所

配置場所は公式

にも記載がある3種類で

.github/
- 採用 : GitHub の設定なので今回の場合適切
レポジトリのルート
- 不採用 : レポジトリのルート直下は原則ディレクトリだけにしたいため
docs/
- 不採用 : ドキュメントのレポジトリなので設定ファイルは置きたくない

という話があり .github/ が採用になりました。

設定の単位

CODEOWNERS の各行は以下のルールで対応することになりました。

ディレクトリは原則第一階層指定
- フレームワーク、言語での標準で第二階層以降に分岐を作らないといけない場合はコメントで記載
人の指定は原則チームを指定
- 元々GitHubレポジトリの権限指定がチームだったという単純な理由からです
- ここを個別指定にするとオンボーディング/オフボーディングの作業も増えてしまうので

Rulesets

機能概要

ブランチやタグに関してルール化した制約を適応する機能です。これを利用して誤った操作の防止やレビュー・リリース戦略に沿ったブランチ/タグ運用の促進を試みます。

見直しポイント

割合一般的な内容だと思いますが、主に以下の内容を実施しました。

Branch Protection Rulesets から Rulesets > Branch への修正 ※以前設定したものは当時まだ Legacy な設定として有効でした
ブランチ/タグ全体
- 作成できるブランチの命名規則の制約
- 署名付きコミットの強制
- ファイルパスを制限する(Enterprise版のプッシュルールセット利用)
ブランチ戦略上の定常ブランチに対するもの
- 削除/直Pushの禁止
- PR/マージ
  - マージ前のPR必須
  - PR には承認必要
  - 新規コミットが Push されたときに古い Approval は無効化
  - Approve には CODEOWNERS のメンバーのレビューが必要
  - マージ前に PR のコメント解決、 status check (CIがある場合はCIの成功が要件になっていることが多いです)
  - マージ先の最新のコミットまで取り込まれていることを必須
リリース関係のタグに関するもの
- 作成できるブランチの命名規則の制約
- 更新・削除の禁止

まだ整備中なので、Enforcement Status で Evaluate (※Enterprise 版のルール評価の機能)でルールがうまく動くかの検証をしたり ByPass にレポジトリの設定を行っているチームを指定して試しているところです。

対応できていない代表的なところとしては

マージの戦略の設定
GitHub Actions のトリガー

があります。

GitHub Actions のトリガーに関しては更新ファイルの適切なフィルタリングや、リリース作成時のタグ作成などの個所にまだ課題がある状態です。

Templates & Label

機能概要

issue / Pull Request の作成時テンプレート

とラベル

の管理機能です。

今後１つのレポジトリに複数のコンテキストが混ざってくるのでそれらの分類・整理のために整備を実施することにしました。

見直しポイント

本来的には対応業務・カテゴリごとに作るのがよいとは思いますが、一旦それぞれのチームごとの典型的な issue や PR を元に issue templates と PR templates を事前に作成しました(付随して Label も)。現状重複要素が多いので、そのうちまとめ直す可能性が高いと思います。

特に Label に関しては標準のラベル以外は単純一括移植だったので チーム名:元々のラベル名 になっているなど、要考慮ポイントが残っています。

また、一部のチームでは現在パブリックプレビューの GitHub のフォームスキーマを使おうとしていました。

公式ドキュメントにある

よくあるエラーに引っかかっていたのを見かけました。まだ仕様も変更の可能性もあるのであまり頑張らなくてもいいのかなというのが現在の所感です。

おわりに

見直しの先にモノレポ化や複数チームや生成AIでひとつのレポジトリを操作するという状態が待っています。ガードレールがしっかりしていないとすぐにコンフリクトが起きそうなのでしっかりと整備を進めたいと思っています。

組織的に管理作業は手が空いている人/分かっている人の手弁当状態になっているという大きな課題もあるのですが、来年も生産性向上、インシデント予防、生成AI活用に向けて頑張っていきます。