.png?table=block&id=28b7f9a9-ac26-4a5a-821b-73fd9516ae02&cache=v2)
GitLab Flowとは？
Github flowは単純すぎて、配布、リリースなどの少し複雑な問題を補完するために出てきた戦略です。ブランチの種類が多すぎることで発生する懸念点を考慮して、これを簡素化したのが
Github Flowですが、これより細分化して配布、環境構成、リリース、統合に関するガイドをGitLabで提供しています。pre-production ブランチがない戦略
Github-Flowでは毎回Merge後にデプロイをするように言っていますが、デプロイのタイミングが合わないサービスなど、この特徴を毎回適用するのが難しい場合があります。
このようなケースを解決するためproductionブランチが存在し、コミットした内容を一方的に配布する形を作りました。GitHubでブランチをもう一つ構成して使うこれも少し簡単な構成です。
このように構成すると、デプロイメントが自動化されていない構成でどのようにデプロイを進めるかについて説明しました。もちろん、これだけでは不十分で次のようなことも追加されました。
pre-productionブランチを置いてstaging段階を持つ戦略
masterとproductionの間にpre-productionを置き、開発した内容をそのまま反映させるのではなく、時間をかけて反映させることを言います。Stagingのための空間であるpre-productionにMRをMasterから送ります。このような形式はdownstream flowの方式を取ることになり、hotfix発生時、masterでfeatureブランチを作って修正後、MasterにMRを送ります。featureブランチをすぐに削除せず、Masterでの自動テストを通過したことを確認して削除します。
Gitlab flowのブランチは下記のように使います。feature
全ての機能実装はfeatureブランチから始めます。featureブランチはmasterブランチから分岐してマージされます。
master
Gitlab flowのmasterブランチの役割はGit flowのdevelopブランチと同じです。 masterブランチはfeatureブランチでマージされた機能についてtestを行います。全体的なテストが進んで機能に対する保証ができたらproductionブランチへマージします。もしstaging段階が必要な場合は、pre-productionブランチでマージを行います。
production
Gitlab flowのproductionブランチの役割はGit flowのmasterブランチと同じです。テストが終わった機能についてデプロイをするためのブランチです。pre-production
master → productionブランチの間にpre-productionブランチを置いて、変更内容をすぐにproductionにデプロイせずにtest serverにデプロイして統合テストをしたり、時間をかけて反映するブランチです。
まとめ
Git flowは複雑すぎて、Github flowは単純すぎるという要件にある戦略で、サービスの規模が少し大きくなったチームで使うのに良い戦略だと思います。上で説明した内容よりもっと詳しく知りたい場合はリンクで確認することができます。
今まで
Git flow、Github flow、最後に今回学習したGitlab flowまでブランチング戦略を勉強しながら本当に正解はないと感じました。 それぞれの状況に合ったflowを使えるようにそれぞれの特徴を認識して使う必要があると思いました。
댓글