はじめに
ぐるなびさんが１日ごとにリリースを行う場合はGitflowを使わないという記事を書いていたので、１週間に１度リリースをしている僕の会社のGitフローについて書いてみようと思います。
「GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します」
開発の流れ
図が汚くて申し訳ございません。
featureブランチはreleaseブランチから作ります。
featureブランチで開発中のものはいつでもdevelopブランチにpushできます。
featureブランチで開発を終えたらreleaseブランチにプルリクエストします。同時にdevelopブランチにもpushします。
その週のリリース物が集まったらstagingにマージしてE2Eテストをします。
問題なければmasterにマージします。
developブランチはチームに一声かければいつでも削除して新しくreleaseブランチから作ります。
特徴
- developのブランチの役割がGitflowやGitHubFlowなどとは異なります。
実験的な変更を試したり、フィードバックを貰うための環境を作ったり、プルリクエストで簡単な動作チェックなどをするためにdevelopブランチを使っています。 - リリース物を集約するreleaseブランチが存在します。
GitLabFlowの考えに近いものですが、フローが複雑になるのが嫌なのでstableのリビジョンは省いてます。 - pre-productionの位置付けのstagingが存在します。
E2Eテストを行います。品質確保の要です。
前提
僕の会社ではスクラム開発を行っていています。
原則、1スプリント1週間、1スプリント1リリースのサイクルです。
- 水曜日：（午前）リリース、（午後）スプリントプランニング
- 木曜日：スプリント
- 金曜日：スプリント
- 月曜日：スプリント
- 火曜日：（午前）スプリントレビュー・レトロスペクティブ、（午後）リリース準備、自主学習
また、ソフトウェアが動く環境として下記の環境を用意しています。
- 本番環境(Production)
- ステージング環境(Staging)
- 開発環境(Develop)
環境はすべて異なるサーバー、DB、ネットワーク構成で構築しています。
master/staging/developのブランチにプッシュすると、自動的にテストとデプロイが行われます。
GitFeatureFlowとの比較
ぐるなびさんの表を元にうちのフローを評価してみました。
| 比較する項目 | GitFeatureFlow | うちのFlow |
|---|---|---|
| 複数案件対応 | ◎ | ◎ |
| 大規模開発向き | ◎ | ◎ |
| 小規模開発向き | ◎ | ◎ |
| シンプルなフロー | ○ | × |
| リリース時期の調整 | ◎ | △ |
| リリース日の変更 | ◎ | △ |
| コンフリクト関連 | △ | ○ |
あれ？GitFeatureFlowより劣っている？🤔
うちの場合はリリース日が固定なので、あまりリリース時期を調整するとか変更するとかで悩んだ事なかったよね・・・。
例外として、緊急リリースしなければならない場合はHotfix的なブランチを作成してすぐにリリースしてしまいます。
代わりにうちは下記のようなものを重要項目としてしています。
| 比較する項目 | うちのFlow |
|---|---|
| 開発環境で思う存分実験できる | ◎ |
| リリース計画に沿った開発物を集約できる | ◎ |
| ステージング環境で品質を確保 | ◎ |
| ステージングと同じものが本番で動いている安心感 | ◎ |
おわりに
会社ごとにいろいろなGitの使い方があるんだと知りました。うちの会社に入ってきた人は、あまりのフローの複雑さに戸惑う人も多いので、もっと簡単にしたい気持ちもあったりします。
参考になればと思います。