2023/03/29
モノレポの構成で複数チームが開発するなら GitHub の CODEOWNERS を設定しようという話です。
GitHub の設定でファイルやディレクトリに対してユーザもしくはチームを指定することで、レビュワーの自動アサインをはじめとした機能を使えるようになる。設定方法は GitHub の公式ドキュメントで丁寧に紹介されている。
モノレポ構成で開発を進めている場合、領域ごとに特化して分担することになるので CODEOWNER の指定は必須になってくるだろう。特に複数チームで開発している場合に CODEOWNER 設定を徹底することで逆コンウェイ戦略を後押しする力となり、チームがナワバリとしたいコードの領域が明確になっていくだろう。
コードオーナーを設定しているファイルに対して変更があった場合、レビュワーを自動でアサインすることができる。GitHub のチームを設定している場合、コードオーナーにチームを設定することで、チーム内の誰かを交代でアサインするような使い方も可能になる。
コードオーナーを設定しておくことで、プルリクエストの Files changed タブのフィルターに "Only files owned by you" という項目が追加される。この項目にチェックを入れることでコードオーナーに設定されているファイルのみを絞って表示することができる。
この機能によって、モノレポの全体に変更が入るような設定の変更があったとしても、コードオーナーとなっている範囲に対してのレビューしやすくなるので大きい PR への抵抗感を軽減できる。
私が考える実務でのコードオーナー設定の進め方を紹介しておきたい。半分くらいモノレポの説明になってしまった。いろいろ書いたが、まだまだ実務でも取り組んでいる最中ではある...。
以下の設定で全体のコードオーナーを設定できる。これによってコードオーナー未設定コードは全てテックリードにオーナーを任せると運用としつつ、段階的にコードオーナーの設定を分割していくことができる。
* @92thunder
このやり方を再帰的に実行し、まずは大きい粒度でオーナーを定め、徐々に適切なオーナーに割り振っていくと進めやすいだろう。
これはフォルダの分割方法について合意を得る仕事になり、議論が白熱するポイントになるだろう。はじめのうちから複雑なフォルダ構成にする必要はないので、まずは切り口を考えすぎずフラットにディレクトリを配置しても問題ない。
フォルダの切り口としては、ドメイン・技術、プラットフォームなどさまざまな切り口があり、さらにそれらを組み合わせたネスト構造が考えられるため複雑になるだろう。切り口については以下のブログが参考になった。
https://dev.to/this-is-learning/semantic-grouping-folders-with-nx-3467
私はチームトポロジーに見られるようなチームファーストの考え方に従って、とにかくチームが動きやすくなるような構成を目指していくべきだと考えている。
とにかくコードを分割し、CODEOWNER の設定範囲を広げていく。
コードの分割にはモノレポ管理ツールが役立つ。私が業務で使っている Nx というモノレポ管理ツールでは libs というモジュール群を組み合わせて app を作るというメンタルモデルに則っており、この考え方もコードの分割を後押しする材料になる。
A common mental model is to see the application as "containers" that link, bundle and compile functionality implemented in libraries for being deployed.
自動でレビュワーアサインされるようになると、人間のアンチ仕事機能によってこれもレビューしなくちゃいけないのかという気持ちが働く。それにより以下のような気づきを得られるだろう。
この気づきによってコードオーナーの設定だけでなく、コード構成・アーキテクチャ・チーム構成などの改善の機会にもなるだろう。
モノレポ構成でスピードを落とさず開発するために CODEOWNER の設定は必須だと考えているので、小さいところからでも設定していく機会になれば幸いです。
業務でのモノレポ経験は貴重なので、今後もこういったテクニックを紹介していきたい。