GitHubの review assignment 機能を使用してラウンドロビンでレビュアーを自動選定する。指定された方はベストエフォートでレビューを行う。レビュー時に指摘や疑問に思ったことはPull requestのコメントに記入またプルリクのテンプレート機能を使って、レビュアーにプルリクの説明を伝えるように工夫。新規メンバーにはレビューを通してチームが何をやっているのか簡単に把握してもらい、仕事やっている感を感じてもらう。

結果 ⭕️

業務的観点の評価は分からない(評価方法も考える必要あり) 技術的観点からいうとバグ・typoの指摘やコードの書き方などコメント上でやりとりがあったので、主観的ではあるが一定の効果はあったと思われる。

この4月からはレビュアーの負担を考慮して、チーム内の担当領域を大きく２つに分け、その中でアサインをすることになった。
ノウハウの共有とそれによる負荷のバランスの調整を今後も行っていきたい。

また今後の課題としてコードレビューがチーム開発にもたらした効果を評価する仕組みを作る必要がある。

4. バラバラだったブランチ戦略を統一化

課題

リポジトリごとにdeploy方式が異なっていたため、CI/CD時を念頭においたブランチ戦略も異なっていた
- ex) handsnet-api: developブランチ→stg、masterブランチ→prod

方法

第1フェーズ: master & develop & feature ブランチ並行稼働

施策以前はリポジトリごとにブランチ戦略が異なっていたので、新規作成・変更可能なリポジトリは統一した。以下のような理由から本番はmaster、ステージングはdevelop、ローカル開発はfeatureブランチに紐付けた戦略をとった。

新規参入の開発者がスムーズに合流可能
テスト/rebase/revert単位の矮小化
コンフリクトの減少
バグ修正なのか、機能追加なのかをブランチ名で判断可能
ステージングと本番で稼働しているコードとブランチを紐付け

↓ブランチの関係を図に起こしたもの

しばらくはこの方法を続けていたが、運用していく中でいくつか課題が見つかった。

masterにマージするためだけにdevelopブランチを起点としたプルリクを作成
ステージングでテストするためにdevelopブランチにマージしなくてはならない
- 気軽にステージングでテストできない
GitHubの機能でmasterブランチ(デフォルトブランチ)でないと使用できないものがあった

これらの課題があったので第2フェーズではブランチのシンプル化を目指した。

第2フェーズ: master & feature へシンプル化

ステージングで気軽にテストするためと主要ブランチをわかりやすく1つにするためにmaster & featureブランチのみにした。CI/CDを使用して気軽にステージングでテストできるように {Ymd}.stg.{sequence} タグを打てば自動でステージングにデプロイしてテスト可能にした。masterにマージされたタイミングで自動でステージングにデプロイするようにしたので最新のコードがステージングで稼働するようになった(タグでステージングにデプロイするリポジトリもある) 。本番へのデプロイは {Ymd}.{sequence} タグを打てばいいので任意のタイミングでデプロイ可能になり、複数のプルリクをマージ後にまとめてデプロイできるようになった。

↓新Git Branch & Tag Flow

結果 ⭕️

基本的にfeatureブランチ → masterブランチに集約された
- ブランチ名をつけやすくなった
- Backlogとの紐付けをAutolinkで実施するようにした、というのも一因
tagのおかげで前回との差分がわかりやすくなった
変更をまとめてデプロイすることが可能になった
featureブランチをステージングで気軽にテストできるようになった

5. モブリリース対象の制限

課題

CI/CDの導入前にモブリリースを導入していたが、CI/CDを導入後にもほぼ全てのリリース作業はモブリリースしていた。そうなると自動デプロイを見守るだけの時間が発生してメンバーの時間を奪ってしまう懸念があった。

方法

プルリクにモブリリース ラベルをつけることで、モブリリースの対象かそれともソロリリースするのかをフィルタリング可能にした。また、前提としてレビュー済み・事前にリリース連絡は必須とした。モブリリース とするのは原則としてgit操作などの手作業があるリリースや、本番への破壊的は変更がある場合にすると周知を行った。