はじめに
ぐるなびさんが1日ごとにリリースを行う場合はGitflowを使わないという記事を書いていたので、1週間に1度リリースをしている僕の会社の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の使い方があるんだと知りました。うちの会社に入ってきた人は、あまりのフローの複雑さに戸惑う人も多いので、もっと簡単にしたい気持ちもあったりします。
参考になればと思います。