TL;DR
オートデプロイ実装するついでにgit-flow導入を検討中。
リリースブランチで最終ステージングテストするよ。
背景
手動デプロイからオートデプロイに切り替えるプロジェクトを担当しています。
オートデプロイを実現するにあたって業務フローを見直していたところ、Gitの運用も今のままだときついのでGit-flowに変えましょうという話になりました。
Git-flowとは？
Gitの運用に関するベストプラクティスの一つです。
提唱元はこちらです。
A successful Git branching model
https://nvie.com/posts/a-successful-git-branching-model/
日本語だと以下の記事が大変良くまとまっています（すばらしい！）
gitの運用ワークフローのメモ（git-flow、github flow等）
https://qiita.com/ta-ke-no-bu/items/a9854deb61419a0d64c7
Gitにある程度慣れたユーザは「ブランチをどう切ってどうマージするか？」という問題にぶち当たると思います。
そしてこれには正解がない。業務上のコード管理をどうするかという問題そのものだから。
でもとりあえず悩んだらベストプラクティスから選択してそれに沿うのは賢いやり方です。
料理の素人はレシピ通りに作りましょう。オラそこ隠し味入れてんじゃねぇ！
現在のGit運用
ざっくりこんな感じの運用をしてます。
- master: 本番コード
- pj_xxx/dev: プロジェクトごとの開発ブランチ
- pj_xxx/nyaaan: プロジェクトごとの作業ブランチ
- issue/zzz, feature/heyhey, hotfix/vivivi, bugfix/owata: その他有象無象
なんか細かい命名ルールあったけど忘れた。（オレオレルールだと普及も大変です）
trunkブランチもかつてありましたが滅ぼしました。（お察しの通りかつてsvn管理でした）
正直master以外管理されていないです。
リリース時には本番環境よりmasterコードが先行する形になります。
現運用の課題点
ざっくりこんな感じ。
1. コンフリクト問題
- 開発ブランチ間でコンフリクトしたときに泣ける
- 開発ブランチがmasterちゃんと追従していない場合がある
- 直前のバグ修正の影響で開発ブランチがコンフリクトしてマージできない
- 直前のバグ修正を取り込み漏れでmasterのUTコケてる
2. リリース中断時の問題
- リリース中に問題が発覚して撤退した場合masterブランチにrevertを積む必要がある
3. 不思議ちゃん
- masterに積まれてるけどデプロイされてない変更があるぞ？
特に今回問題を感じたのは１，２です。（3は自動デプロイしようね）
オートデプロイに乗せるにあたって先にmasterに積んでそれを起動としてしまうと、巻き戻しが発生したときに本質でない変更コミットがガンガン積まれます。
それを避けるためにはmasterは本番変更よりもあとに更新。
共通のdevelopブランチでコンフリクト解決やリリース直前テストをしておきたい。
Git-flow選択の理由
現運用がほとんどまともにブランチ管理していないので、ベストプラクティス輸入して当てはめるのが一番早いです。
詳細にブランチ運用を定義するための情報も得られてないですし。
他にGitHubFlowとか色々あるのですが、現状うちのプロジェクト進行を鑑みるに、最終調整のdevelopブランチは不可欠ということでgit-flowベースで設計を進めることにしました。（GitHubFlowの方は比較的少人数向きかな？）
Git-flowのデプロイパイプラインへの当てはめ
元記事の以下のイラストをベースに説明していきます。
A successful Git branching modelより引用
メインブランチ(develop/master)
Git-flowにおいて永続するブランチはこの２つのみです。
masterよりdevelopが先行して、デプロイ直後に追いつく形になります。
（主にやりたかったのがこれ）
この２つのブランチは更新を検知してUTを回して方針です。
リリースブランチ(release/x.y.z)
リリース作業の間だけ存在するブランチ。
developから派生して、デプロイ後にdevelopとmasterにマージされます。
本番環境にはこのブランチをデプロイすることになります。最終クッション。
作成を検知してステージング環境に自動デプロイしてステージングテストができるようにします。
軽微なバグの修正はここにコミットが積まれます。（深刻なバグ？撤退しろ）
２つ以上同時に存在する予定は無いもののバージョン番号のブランチ名つけておいたほうが無難でしょう。
Featuresブランチ
その他諸々の変更を積むブランチ。プロジェクトの開発ブランチもこの一部。
developから派生してdevelopにマージします。
Hotdixesブランチ(hotfix/x.y.z)
緊急用。上記のブランチルールによる運用回してられないような危機的状況向けです。
masterから直接派生してmasterとdevelopにマージされます。
実際の運用としては、本番環境を直接触って後付でコミット積む形になると思います。
このブランチ採用すべきか議論を呼んだんですが、結果入れることにしました。
理由としては以下の２点です。
- デプロイパイプラインは初めは安定しないと思われる
- うちのサービス特性上、一刻を争う危機的状況は起こり得る
1はともかく2の理由があるので廃止することはなさそうです。
まとめ
- オートデプロイするうえでgitの運用はちゃんとしような
- 迷ったらベストプラクティス使っとけ
- 開発規模でかいならgit-flowおすすめやで
- ステージングテストはリリースブランチでしよう