昔は Subversion を使っていましたが、ここ数年は Git をメインで使うようになりました。特に現在参画しているプロジェクトでは基本的に月1でリリースがあり、開発の柔軟さやレビューのしやすさを考えると、やはり Git が適していると感じます。
ブランチモデルとしては、GitLab Flow のようなフローを採用しています。(実際に導入したのは自分ではないですが)
個人的には GitLab Flow は Git Flow より簡単で GitHub Flow より堅牢なブランチモデルという印象です。
about.gitlab.com
ブランチモデルは、代表的なフローをそのまま導入するのではなく、現場の状況や制約に合わせて柔軟にカスタマイズする方がよいです。
現状
現在の運用では、master を開発のメインブランチとして、開発機能ごとに feature ブランチを切っています。また、機能の実装が終わったらマージリクエストを投げて master にマージします。一応、pre-production ブランチがあるのですが、最近は怠慢の極みで master をそのままリリースしています...。本番環境のリリースが終わったら production ブランチにマージします。
で、現実問題として、例えば次のようなケースが発生します。
- 2019/08 向けの開発と2019/09 向けの開発が並行する
- ある機能が master にマージされたあとにリリース延期やペンディングになる
こうなると、メインブランチ1本の運用は若干心細い感じに。
現在の運用でもある程度はうまく回っているのですが、どうすればこれらの問題を解消できるか。以降はそのあたりを検討した際のメモです。実際に運用しているわけではなく、あくまでも 案 です。
ちなみに、GitLab と Redmine を使っているので、その環境を前提としています。ただし、バージョンはここでは書けないくらい古いため、お察しください。
課題
要件
最低限どういうブランチが必要か。
- 本番環境同等のブランチ
- 開発のベースとなるブランチ (並行運用あり)
検討事項
- どのブランチをメインブランチとするか
- マージ漏れをどうやって回避するか
- 柔軟なリリースをどうやって実現するか
運用案
ブランチ
master: 本番環境同等のブランチrelease/yyyyMM: リリースブランチdevelopment/yyyyMM: 開発メインブランチfeature/#{チケット番号}: 作業ブランチ
feature/#{チケット番号}_#{子チケット番号}: 作業ブランチの子ブランチ
hotfix/#{チケット番号}: 緊急のバグ修正ブランチ
毎月のリリースに合わせて開発メインブランチを切る。リリースする機能が fix したタイミングで master からリリースブランチを切る。リリース延期やペンディングなどがなければ開発メインブランチをそのままマージする。リリース延期やペンディングがある場合は、リリースする機能の feature ブランチからリリースブランチにマージリクエストを投げる。cherry-pick は使わず、マージリクエストだけで完結させる想定。
リリースが完了したら release ブランチを master にマージしてタグを作成する。開発が並行している場合は次期リリースの開発メインブランチに master をマージする。
基本的に master 以外は使い捨て。
- リリースバージョン
- 命名規則:
release{yyyyMM}
マージリクエストにはマイルストーンを設定する。リリース対象から外れた機能はマイルストーンを再設定する。こうすることで、未リリース機能のマージ漏れを防げる想定。GitLab のマージリクエスト画面ではマイルストーンでフィルタリングできるので便利。
マージリクエスト
マージリクエストを投げる際のルール。
- タイトル: 「#{チケット番号} {対応内容 or チケットタイトル}」
- マイルストーン:
release{yyyyMM}
フローイメージ
残課題
- リリース延期が発生した際、リリース対象のブランチを漏れなくリリースブランチにマージできるか
- チケット管理と組み合わせてマージ漏れを防ぐ？ or GitLab の Issue で管理してみる？ (☆要検証)
- ブランチが増えすぎて運用コストが負担にならないか
- リリース済みのブランチは削除する？
- 未リリースの feature ブランチは残す (release ブランチに個別にマージするケースを考慮して)
- 開発/リリースのブランチを作成するコストが負担にならないか？
- 月1程度なので頑張る？ or CLI ツールを自作する？
- デプロイするブランチを切り替える作業が負担にならないか
