Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?

13,935 views

Published on

GitFlow,GitHubFlow,GitLabFlowは使わない!
gitの新しいブランチモデル「GitFeatureFlow」を
考えたので紹介します

Published in: Technology

新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?

  1. 1. GitFlow,GitHubFlow,GitLabFlowはもう使わない! GitFeatureFlow   を紹介します by naoki koyama
  2. 2. 名 前:小山尚樹 勤務先:株式会社ぐるなび スキル:2人の子供がいるので、     家事&育児スキルがレベルアップ中 自己紹介 2
  3. 3. あらすじ 1-Gitのブランチモデル検討に困った。。。 2-GitFlow,GitHubFlow,GitLabFlowでもダメだった 3-GitFeatureFlowを考えた 4-2500回以上リリースしてるが、めちゃめちゃ楽になった 3
  4. 4. こんな人は必読 1-GitFlowを使ってる人 2-GitHubFlowをカスタマイズして使ってる人 3-動作確認後、すぐに本番リリースできない人 4-リリース日調整が大変な人 5-急なリリースが多く発生する人 4
  5. 5. 有名なブランチモデルが適用できなかった理由 GitFlow GitHubFlow GitLabFlow フロー自体がかなり複雑で 毎日リリースしたり、リリー ス日を変更するスタイルに は向いていない。 本当は1番使いたい。 ただ、品質管理チームの 確認作業が発生する為、 即リリースができず使えな い。 GitFlowよりシンプルだが、 リリース日の変更に柔軟 に対応できない。 5
  6. 6. ブランチモデルの比較 (あくまでも個人の感想です。) 比較する項目 GitFeatureFlow GitHubFlow GitFlow GitLabFlow 複数案件対応 ◎ ◯ ☓ ◯ 大規模開発向き ◎ △ ◎ ◯ 小規模開発向き ◎ ◎ ☓ △ シンプルなフロー ◯ ◎ ☓ △ リリース時期の調整 ◎ △ ◎ ◎ リリース日の変更 ◎ △ △ △ コンフリクト関連 △ △ ◯ ◯ 6
  7. 7. GitFeatureFlow 7
  8. 8. 説明の流れ GitFeatureFlowはGitHubFlowを参考に考えているので、 下記の流れで説明します。 1-GitHubFlowの流れ 2-GitHubFlowを採用できない理由 3-GitFeatureFlowのポイント 8
  9. 9. 3-masterとの差分をレビュー  (pull request) GitHubFlowの流れ master feature branches 1-masterからbranchを作成 4-masterにマージして  本番環境へリリース 2-実装 9
  10. 10. GitHubFlowを採用できない理由 master feature branches  レビュー完了後、即本番環境へ出来ない。  つまり、リリース時間をコントロールできない。 【例】  開発者以外の動作確認を待つ必要がある。  iOSアプリの場合は、AppStoreの審査を通過する必要がある。 10
  11. 11. GitFeatureFlowの流れ 11
  12. 12. こんな開発を想定 1-動作確認やアプリ申請の為に、即リリースできない 2-毎日リリースする 3-急なリリースがよく発生する 4-大小様々なプロジェクトが同時に稼働している 5-リリース日の変更が多い 12
  13. 13. 3-masterとの差分をレビュー  (pull request) GitFeatureFlowの全体の流れ master feature branches 1-masterからbranchを作成 5-テスト環境での動作確認後、  masterにマージして  本番環境へリリース test-env テスト環境と同期されているブランチ 4-test-envとマージして、  テスト環境へリリース  動作確認を行う 2-実装 13
  14. 14. 3-masterとの差分をレビュー  (pull request) GitFeatureFlowの流れ1 master feature branches 1-masterからbranchを作成 5-テスト環境での動作確認後、  masterにマージして  本番環境へリリース test-env テスト環境と同期されているブランチ 4-test-envとマージして、  テスト環境へリリース  動作確認を行う 2-実装 masterとfeature branchesの関係だけ見ればGitHubFlowと一緒です。 通常開発やバグ改修に関係なく、masterからfeature branchを作成します。 14
  15. 15. 3-masterとの差分をレビュー  (pull request) GitFeatureFlowの流れ2 master feature branches 1-masterからbranchを作成 5-テスト環境での動作確認後、  masterにマージして  本番環境へリリース test-env テスト環境と同期されているブランチ 4-test-envとマージして、  テスト環境へリリース  動作確認を行う 2-実装 環境ごとにその環境と同期されているブランチが存在します。 例:テスト環境の場合はtest-env、ステージング環境の場合はstg-env等 15
  16. 16. 3-masterとの差分をレビュー  (pull request) GitFeatureFlowの流れ3 master feature branches 1-masterからbranchを作成 5-テスト環境での動作確認後、  masterにマージして  本番環境へリリース test-env テスト環境と同期されているブランチ 4-test-envとマージして、  テスト環境へリリース  動作確認を行う 2-実装 テスト環境で動作確認をする場合は、test-envにfeature branchをマージします。 16
  17. 17. 3-masterとの差分をレビュー  (pull request) GitFeatureFlowの流れ4 master feature branches 1-masterからbranchを作成 5-テスト環境での動作確認後、  masterにマージして  本番環境へリリース test-env テスト環境と同期されているブランチ 4-test-envとマージして、  テスト環境へリリース  動作確認を行う 2-実装 本番リリースが確定した時点で、feature branchをmasterへマージします。 17
  18. 18. 4-test-envとマージして、  テスト環境へリリース  動作確認を行う 3-masterとの差分をレビュー  (pull request) GitFeatureFlowのフロー補足 master feature branches 1-masterからbranchを作成 6-ステージング環境での動作確認後、  masterにマージして  本番環境へリリース test-env テスト環境と同期されているブランチ stg-env ステージング環境と同期されているブランチ 5-stg-envとマージして、  ステージング環境へリリース  動作確認を行う 2-実装 補足:複数環境が存在する場合は、それぞれにfeature branchをマージします。 18
  19. 19. GitFeatureFlowのポイント 19
  20. 20. ポイント 1-feature branchが独立し、他のブランチと依存関係にない 2-環境ごとにその環境と同期がとれたブランチが存在する 3-feature branchを環境ごとのブランチにマージする 4-コンフリクト発生時も修正は必ずfeature branch内で行い、  master以外の他のブランチをマージしない (masterだけはマージしてもOK) 5-レビューは常にmasterだけ行う  (他のブランチでレビューしない) 20
  21. 21. feature branchが独立し、 他のブランチと依存関係にない とは? 21
  22. 22. 標準的なGitFlowを使って複数案件を対応している場合 22
  23. 23. GitFlowの場合 develop feature branches release branch 複数案件を対応中 GitFlowで複数案件を対応している場合は、developからrelease branchを分岐するので、 developが安定した状態である必要がある。 23
  24. 24. 1つの案件のリリース日が変更になったら・・・ 24
  25. 25. 即死亡 25
  26. 26. 本当はGitFlowでも対応はできるが、 方法がかなり煩雑になるため、 出来る限りやりたくない。。。 26
  27. 27. 1つの案件のリリース日が変更になった develop feature branches release branch 複数案件を対応中 2つの案件をdevelopにマージしている為、片方の案件をdevelopから 取り除く必要がある。つまりブランチ同士の依存関係ができてしまっている。 27
  28. 28. GitFeatureFlowの場合 28
  29. 29. 1つの案件のリリース日が変更になった master feature branches 複数案件を対応中 テスト環境と同期されているブランチ test-env GitFeatureFlowで複数案件を対応している場合。 29
  30. 30. 1つの案件のリリース日が変更になったら・・・ 30
  31. 31. ブランチをマージしなければいいだけ! 31
  32. 32. 1つの案件のリリース日が変更になった master feature branches 複数案件を対応中 テスト環境と同期されているブランチ test-env 赤くなっているのが、リリース日の変更があったブランチのマージ。 このマージをやめればいいだけ! 32
  33. 33. 1つの案件のリリース日が変更になった master feature branches 複数案件を対応中 テスト環境と同期されているブランチ test-env 各ブランチが独立していて依存関係にないので、他のブランチを気にせず、 masterへのマージのタイミングを変えればいいだけ。 33
  34. 34. まとめ テスト環境 ステージ環境 本番環境 GitFlow GitFeatureFlow feature A feature B develop feature A feature B feature A feature B develop feature A develop feature A feature B feature A feature A GitFlowはdevelopをマージしていく為、AとB案件が依存状態にある。 GitFeatureFlowはAとB案件が独立している為、リリース日変更が容易。 feature B Bを取り除くのが大変 feature A develop feature B Bを取り除くのが大変 環境 Flow 34
  35. 35. GitFeature Flowの実際の作業 35
  36. 36. 事前準備 以下、事前準備です。 1-リポジトリ作成 2-環境ごとにmasterからブランチを作成  例:テスト環境の場合、test-envなど 3-環境ごとにブランチと同期を取れる仕組みを構築  とはいえ、テスト環境の場合は、test-envとrsyncを行うだけでいいはず。 36
  37. 37. 作業の解説 37 これから実際の作業を解説します。 わかりやすいように下記作業を詳細に解説します。 1-ある案件をコーディングして、レビュー後にテスト環境に反映 2-動作確認によりバグを発見し、再修正して、テスト環境へ再反映 3-ステージング環境へ反映し、動作確認後、本番リリースを行う
  38. 38. 作業1 「1-ある案件をコーディングして、レビュー後にテスト環境に反映」 01-masterからブランチ(ex:new_feature)を作成  (通常案件でもバグ改修でも同じフロー) 02-new_featureをコーディング、commit、push 03-masterとnew_featureの差分比較を行いレビュー  (pull requestがあれば尚良。ただし、マージは絶対にしない)  レビューは常にmasterとだけ行う 04-test-envにnew_featureをマージする 05-test-envをテスト環境へリリースする 38
  39. 39. 作業2 「2-動作確認によりバグを発見し、再修正して、テスト環境へ再反映」 06-テスト環境で動作確認し、バグを発見 07-new_featureをコーディング、commit、push 08-masterとnew_featureの差分比較を行いレビュー  レビューは常にmasterとだけ行う  test-envとレビューした場合は、他の案件の差分も出てしまう 09-test-envにnew_featureをマージする 10-test-envをテスト環境へリリースする 39
  40. 40. 作業3 「3-ステージング環境へ反映し、動作確認後、本番リリースを行う」 11-stg-envにnew_featureをマージする 12-stg-envをステージング環境へリリースする 13-ステージング環境で動作確認を行う 14-masterにnew_featureをマージする 15-masterを本番環境へリリースする 40
  41. 41. 補足 テスト環境 ステージ環境 本番環境 マージタイミング いつでも良い 本番リリースの 1日前に反映 毎日10:00に反映 マージ依頼方法 (マージしたいブランチごと に依頼する) 依頼せず個人で反映 stg-envにpull request してあるもの masterにpull request してあり、マイルストー ンが当日のもの マージするブランチ feature A feature B 補足として、運用のコツです。(死守する必要はありません。) 複数案件を同時にリリースする場合は、環境ごとにマージするタイミングや依頼 方法を決めておくと自動リリースなどが行いやすいです。 環境 41 feature C feature A feature B feature A feature B
  42. 42. コンフリクトが起きた時は? 42
  43. 43. コンフリクトが起きた時は? 1-他のブランチをマージせず、コンフリクトが起きてる2つのブランチを確認して、  コンフリクトが起きてる「行」だけを正しい形に修正します。 2-正しい形になっているかどうかはmasterとの差分比較を見て、  その状態でリリース可能かどうかを判断します。 3-コンフリクトした時は、それぞれのブランチに最新版のmasterを  マージすると解消する場合があります。 -補足- 他のブランチをマージしないのは、それぞれのブランチの独立性を守ることで、  リリースの柔軟性を維持し、他の人の作業を気にせずリリースできるように しているからです。 43
  44. 44. Q&A 44
  45. 45. Q: GitFlowの場合は、1つの案件を進めると他の案件が進めづらいので、 リリース日と順番を厳粛に守るように運用しています。 GitFeatureFlowを使うとそれが解消されるのでしょうか? A: はい。解消されます。 リリース日の変更などに柔軟に対応できるようになり、 複数案件を同時に進めれるので、開発効率とスピードが格段に上がると思います。 45
  46. 46. Q: 複数案件をまとめてリリースする場合のマージはどこでやるんでしょうか? A: まとめてリリースする場合も1つずつfeature branchを環境ごとのブランチにマージしてい きます。テスト環境、ステージング環境、本番環境の3つの環境に リリースする場合は、案件ごとに3つのブランチにマージする事になります。 46
  47. 47. Q: GitHubFlowでDockerを使って、ブランチ毎に確認環境を自動生成しています。 GitFeatureFlowの必要性がわからないのですが? A: 1つの案件の確認で業務が回る場合は、とてもいいやり方だと思います。 ただし、複数案件が存在している状態を確認しようと思った時には、上記方法は使え ません。 47
  48. 48. 最後に 48
  49. 49. 最後に GitFeatureFlowを導入してから、3年弱、2500回以上リリースを行ってきましたが、この フローが原因でのバグは一度も出ていません。 何よりリリース日を気にすることなく、シンプルなフローで作業ができて、 心理的にもいいことばかりです。 皆さんもステキなGit生活をお過ごし下さい! 49
  50. 50. おわり 50

×