人数が増えてくると、何を、どのくらいdeployするか戦略を立てないといけなくなる。
リリースモデルケース
A successful Git branching model » nvie.com
次にデプロイされるのは何なのかがある程度分かっているのが利点。
masterはmergeするのみ
developブランチで開発を行う。
developからfeatureブランチを作る
開発が終わったらfeatureブランチをdevelopにmerge
mergeしたdevelopをStagingチェックする
branchでbugfixする
developにmergeする
masterからbugが見つかったらhotfixesブランチを切り、
直接masterにmergeする
このスタイルだとばんばんdeployできない。
GitHub Flow
GitHub Flow – Scott Chacon
リリースマネージャーがいない(全員がdeployできる)
master(origin/master)からデプロイを行う(ローカルのmasterからブランチは切らない)
開発が完了したらPRを出す
PRを処理した人がdeployする。
レビューしないとPRを出せないようにする
小さいPRをちょくちょく出せる環境でないと機能しない
PRを出すなら他のひとのPRもレビューする!!
(テストで守られているのが大前提)
ふわっとレビューしてふわっと出すスタイルなので、
テストをきちんと書くこと。
masterと本番はイコールなので、masterにmergeしたら
すぐにdeployすること!
