前回 は継続的にデプロイしてるよって話をしたので、その流れで今日からちょっと Git を使った開発フローに対するデプロイについて考えてみたいと思う。まず最初はやっぱり Git-flow からかな。と、その前に
前置き
- 自分は CircleCI だとどうなるかなぁとか考えながら書いてるけど、どの CI サービス・ツールを使っても大丈夫
- 自分の頭の中にあるのはウェブ系の自社サービス。スマホアプリとか組み込みとかは経験がないから分かんない
- どんな風にテストを実行するかみたいな話も面白いけど、今回は CI のことは忘れてデプロイだけ考える
- どのフローが良い・悪いという話ではない
Git-flow
ということで Git-flow 。この絵は有名ですね
どこが始まりなんだろう？って思ったら2010年のこの記事みたい：
2020年に注意書きが追加されてて「（意訳）継続的デリバリーしてるならもっと軽量のフローの方がいいかも。バージョンをつけてる場合や複数バージョンを管理する場合には Git-flow は合ってるかも。自分で考えて決めてね！」って書いてある。良い。
今日のブログの図は↑の記事から引用してます
基本の流れ
基本の流れはこう
- develop ブランチで開発
- リリース可能な状態になったら main ブランチにマージ
なので main ブランチは基本的にリリース可能な状態になってる
基本の流れのデプロイ
この場合のデプロイは自動でやるならこうかな：
- develop ブランチに変更がプッシュされたら自動でステージング環境にデプロイ
- main ブランチに変更がマージされたら自動で本番環境にデプロイ
というのが考えられる。これは、たぶん次回に触れると思う GitLab Flow と同じということになる（develop→development, main→production）
でも、Git-flow を採用したい場合って、デプロイのタイミングは自分でコントロールしたいんじゃないかなぁ。なので、例えば、本番環境へのデプロイを自分でコントロールしたい場合は
- クリックすると main ブランチからデプロイされてタグが打たれる
または
- リリースタグを打つとデプロイされるようにしておいて、main ブランチにリリースタグを打つ
になるかなぁ。develop からのデプロイもコントロールしたい場合は、同じようにしたらいい。Git-flow で、かっちりやりたい場合は、個人的にはワンクリックデプロイが好きかな。まとめるとこう
- develop ブランチからワンクリック（またはタグ・自動）でステージング環境にデプロイ
- main ブランチからワンクリック（またはタグ・自動）で本番環境にデプロイ
release ブランチを使う流れ
と、ここまでは develop と main だけを使った流れだったけど、次は release ブランチを使う流れ
QA とかしてる間に、次の開発を進めておきたいなぁってときは、release ブランチを使う。自分が Git-flow を採用する場合は、release ブランチを使いたいってときだと思う。その場合の流れはこう
- develop ブランチで開発
- 開発が終わって安定したら release-* ブランチを作成
- release ブランチで QA を実施してリリース可能な状態になったら main ブランチにマージ
release ブランチが作成されたら、develop は次の開発に入れる
release ブランチを使う流れのデプロイ
この場合のデプロイはこんな感じ
- develop ブランチから自動（ワンクリック・タグ）で開発環境にデプロイ
- release ブランチからワンクリック（タグ・自動）でステージング環境にデプロイ
- main ブランチからワンクリック（タグ・自動）で本番環境にデプロイ
開発環境なら自動が楽でいいかなと思うので自動を一番最初に、それ以外は自分でコントロールしたいからクリックを一番最初に書いておいてみた。タグについては、本番環境以外では僕は使わないことが多いかな。タグだらけになってしまうから。
hotfix ブランチを使う場合
- hotfix-* ブランチを main から作成して動作確認が終わったら main にマージ
この場合、hotfix ブランチからどこかの環境にデプロイして確認をしたいと思うので
- hotfix ブランチからクリック（タグ）でステージング環境にデプロイ
みたいにやりたい
デプロイまとめ
まとめると、Git-flow を使う場合に僕の好きなのはこういうデプロイだな
- 開発環境
- develop ブランチが更新されたら自動でデプロイ
- ステージング環境（複数ある場合もある）
- ブランチを選択して（develop・release・hotfix・main）ワンクリックデプロイ
- 本番環境
- main ブランチからワンクリックデプロイして自動でバージョンタグを打つ
Git-flow いつ使おう？
良いところ
release ブランチを使わないなら GitLab Flow ってことになるから、release ブランチまで含めて考えると、Git-flow の良いのは、release ブランチで変更をとめてしっかりテストをして安定させることができるところかな。だから Git-flow が合うのは、リリース前にしっかりテストを実施して、そのテストと並行で次の開発が進んだり、複数のリリースを管理したりする必要がある場合かなと思う
難しいところ
Git-flow が必要な環境だと、ブランチの寿命が長くなることが多い。ので、マージを頑張らないといけない。特に複数バージョン管理してる場合は大変そう。それと main や develop に変更が入った場合は、逆向きのマージをする必要があるけど、コンフリクトしないように早めにやっておいた方が良いと思う
いつ使おう？
開発プロセスが複雑な環境では Git-flow が合うと思う。とても便利。
でも本来はそこまで複雑にしなくていいはずなのに、 Git-flow を使うためにプロセスを必要以上に複雑にしてしまう場合があるので、そこだけ気をつけたいかな。「本当にこの Git-flow が自分たちの環境で一番いいのかな？もっとシンプルな開発プロセスや Git のフローでいけるんじゃないかな？」というのは考えたら良さそう
はい、ということで Git-flow のデプロイについてはこれくらい。次は、気が向いたときにシンプルな方のフローを見てみようと思う
