チーム拡大に合わせてブランチ運用をgithub flowに変更した話
はじめに
こんにちは！グロービスでナノ単科の開発を担当しています、nanoチームの矢島です。
今回の記事では、「チーム拡大に合わせてブランチ運用をgithub flowに変更した話」を通して得た知見を皆様に共有したいと思います。
チーム組織成長と成長痛
ナノ単科の開発において、git flowをベースにした開発を行ってしましたが、エンジニアが増えるに従って、プロダクト開発においてストレスを感じるシーンが増えました。
以前までの例として、以下のような仕組みで行っていました。
1.masterから派生したバージョンブランチを切る。
2.バージョンブランチに対して開発内容をコミットする。
3.定期的にまとめてリリースを行うこの仕組みでは、複数の機能がversionブランチに取り込まれるため、リリース後トラブルが起こると知らない機能の仕様読み込みからせねばならず、問題解決に時間がかかります。
リバートするにしても、まとめてリバートせざるを得ない状況が起こっていました。
かつ、リリースの担当者にとって、リリース内容の把握や、リリース後のチケットの後始末など、リリース自体が大きな負担になっていました。
原因を深掘り
なぜ、この課題が発生したのかというのを考えると、
「開発人数が増えたことにより、一度に実装される機能も増えた。よって、たくさんの機能を載せたバージョンブランチをリリースすることそのものが無理が来ているのではないか」
と仮説を立てました。
- 開発人数が、4→10人に増えた結果、一度に実装される機能も増えた。
- 並列で開発している機能が多くバージョンブランチとのコンフリクトが起きる機会も増えた。
- プロダクトのコードが増えたことで、全体の見通しが悪くなった。ゴール設定
ゴール設定を「リリースの負担を減らすために、リリースする機能自体をこまめに出せるようにしたい」としました。
機能ごとに分割してリリースしたい。
リリース作業自体をサイズダウンしたい。
どう改善したか？
ブランチ運用を変更することに手をつけることにしました。
以前までは、git flowをベースにした運用だったんですが、今回github flowに移行しました。
〜〜裏話〜〜
改善活動開始当初、トランクベース開発を参考にフローの改善を行う意思決定をしましたが、トランクベース開発に移行できるほど、テスト自動化や、レビュー体制の構築まではできないと途中で気づき、github flowの導入に留まっています。
git flowベースからgithub flowへ
github flowへ移行したことで、ブランチ管理がシンプルになりました。
開発した機能をmasterにマージするだけです。
ブランチ管理を変更した以上、QAやリリースのワークフローも刷新しました。
具体的には以下のフローで運用されており、開発ブランチ１つが都度リリースされるような仕組みを構築しました。
1.masterから開発用ブランチを切る
2.開発終了後、masterへ向けてPRを切りコードレビューを受ける。
3.開発ブランチを個人の環境にデプロイし、QAがテスト行う。
4.テスト完了後、※リリースチャンネルでリリースすることを宣言する。
5.masterへマージする。
6.stgへデプロイし、挙動チェックをエンジニアが行う。
７.本番へリリースする。
※リリースチャンネルについてはこのあと説明があります。結果的に、当初ゴールにおいていた、リリース対象の分割と、リリース1回あたりの負担を削減することができました。
ブランチ運用変更時の工夫
ブランチ運用変更をすることは簡単ではなく、ブランチ管理以外にも多くの時間を割いたので、少し紹介します。
１：テスト環境の整備
元々、versionブランチをstgデプロイし、そこに開発対象がどんどんマージされる仕組みのため、環境は一つでも良かったのですが、テスト環境を拡張整備する必要が出て来ました。
ブランチごとにテストを行うため、テストする人数分最低限テスト環境を用意する必要がありました。具体的に準備した環境は、以下のうちのstg2,3とdev環境です。
prod・・・本番
stg・・・本番にリリースする前に利用する本番とほぼ同じ環境
stg2・・・QA用 社内システムとの接続なし、機能テストのみに利用できる。
stg3・・・QA用 社内システムとの接続なし、機能テストのみに利用できる。
dev・・・QA用 stg2,3の制限に加えて、破壊的なテストもOK。デプロイにも設定が必要で、backend及び、clientのサービスをそれぞれの環境にデプロイできるようにし、ネイティブアプリもビルドできるように、github actionsの整理も行なっています。
以下のTweetにもある通り、環境構築は、多くの時間がかかりました。
片手間ではありますが2ヶ月ほどかかり、一人で２、３週間あればできるだろうという思い込みはすぐに打ち砕かれました。
本当に助けてくれた、SREやQA、他の開発メンバーに感謝しかありません。
最近勉強になったことで言うと、テスト環境新たに生やすって結構エグい作業量かかるんだなと。
— wataru.y (@yajima_wataru) July 22, 2023
前職でエンジニアが涼しい顔で対応してくれていたのが思い出されるが、terraformの設定、Android、iOS、Webのビルド設定及び、バックエンドの設定などなど、考えていた１０倍作業量多かった。
２：レビューの工夫
github flowに移管したことで、githubのPR欄が「レビュー済みかつQA待ち」のチケットでいっぱいになることが増えました。
そのため、Reviewedラベルをレビュー終了後につけることでどのPRがレビュー済みかをわかるようにしています。
自動化を行っていて、以下のコードを利用して、Reviewedラベルを自動で付与する形を取っています。
３：リリースが重複しないための工夫
リリースが重複しないための仕組みとして、リリースチャンネルを新たに作成しました。
リリースが重複すると事故が起こる種になってしまうため、事前にリリースチャンネルで宣言を行い、リリース中は他のエンジニアはリリースしないというルールになっています。
今のところ重複するようなトラブルは起きていないため、うまく回っているように考えています。
よかったこと。
当初予定していたゴールは達成できました。
さらに、以下のようなメリットも享受することができました。
- FourKeysのスコアが爆上がりした。
- マージ時コンフリクトが減った。
- リリースのリバートがすぐできるようになった。
- 一つ一つの機能しかマージされないため、トラブルの際の原因究明もやりやすくなった。
- みんなリリースできるようになったので、リリースの負担が分散された。
- リリース日が任意になることで、急ぎたいリリースもすぐに出せるようになった。
- 他人の作業を気にしなくてよくなった。
特に意識はしていなかったのですが、fourkeysのデプロイ頻度について爆上がりし、唯一悪かった指標を改善できました。
このことは、他のチームのメンバーからも驚きの声が上がりました。
生まれてしまった課題
今回の改善で反省すべき副作用もあり、今後対応し続けねばなりません。
具体的には２点です。
- 前よりもQAメンバーが忙しくなってしまったこと。
- なんらかのトラブルで、遅れるタスクに気づきにくくなってしまったこと。機能のリリース単位が細かくなってしまったことで、QAメンバーはどのタスクからテスト設計すべきかが読みづらく、流動的な開発チケットの動きを見ながら対応する必要が出て来ました。
作業の複雑度が上がったせいだという仮説を持っていますが、原因の深掘りも含め、QAメンバーが忙しくなっている状況は今後改善すべきです。
また、以前は、リリースバージョンに入るチケット一覧から、versionブランチに入るはずなのに、開発が進んでいないチケットがあれば、周りのエンジニアが気づいて話を聞きに行く機会がありましたが、個別リリースになったことで、遅れがちなタスクが見えにくい状況が生まれてしまいました。
原因は、仕様面の緩さを固めないといけなかったり、技術検証がそもそも必要だったなど、一度チケットの進め方立ち返って企画者や他のエンジニアと相談して進めるべきところを、個人で一人で考え込んでしまえる構造になってしまったことが主な要因だと考えています。
周りが気付ける、一緒に作っていくための仕組みについてはチームでも検討されており、今後対応をしていく予定です。
以上、「チーム拡大に合わせてブランチ運用をgit flowに変更した話」でした。
読んだ皆さんの参考になれば幸いです。
グロービスの開発組織で一緒に働く仲間を募集しています！
グロービスの開発組織では、一緒に働けるエンジニアを探しています！
まずは、カジュアル面談を通して、あなたに合う組織かどうか確かめてみませんか？
https://recruiting-tech-globis.wraptas.site/
この記事が気に入ったらサポートをしてみませんか？