FULL KAITEN の受託開発で複数の開発会社に所属するベトナム人エンジニアチームのマネージメントを行った
- エンジニア同士で相互レビューする文化を根付かせる
- 他人の担当箇所も把握しておくことで属人化を防ぐ
- それぞれが所属する会社の都合等で休暇のタイミングが異なる場合があるので個人に影響されずに一定のベロシティを出せるようにするのが理想
- 指摘するだけでなく設計・コードに関する考え方を共有することが目的
- GitHub Flow を基本として開発フローを定める
- FULL KAITEN 側の開発ブランチとこちら側の開発ブランチは別になっている
- 開発環境も別になっており、それぞれのブランチにマージされると対応した環境にデプロイされる
- FULL KAITEN 側の変更とこちら側の変更はリリースブランチで統合されるのでその時点で差分が大きくなりすぎないように FULL KAITEN 側の変更を定期的に取り込む必要がある
- 変更を取り込む CI を設定
- conflict 等は該当のプルリクエストを見て手動で対応
- リリースブランチへのプルリクエストで FULL KAITEN 側のレビューがある
- チケット単位でプルリクエストを作成
- こちら側の開発ブランチにマージしても feature ブランチを削除せずに残す
- こちら側の開発ブランチを直接リリースブランチにプルリクエストとして出すと単位が大きくなりすぎレビュー側の負荷が大きくなる場合がある
- 修正があればこちら側の開発ブランチに適用してからリリースブランチへのプルリクエストへ反映する
- 次の開発でメインブランチから新たに開発ブランチを切るという方針ではなかったので差分が出ないようにする必要があった