-
- いいね！76
そのっつ (Naotoshi Seo)
@sonots
“Mobile First Development at COOKPAD #deploygate // Speaker Deck” htn.to/LzJPpX
2014-05-30 11:04:28
Yosuke Furukawa
@yosuke_furukawa
@sonots masterは絶対に安定して動作させたいとかそういう思想だよね。developブランチ、 develop で安定してきたらmasterにmergeするって思想だけど、僕も最近作ってない…
2014-05-30 11:16:02
そのっつ (Naotoshi Seo)
@sonots
@yosuke_furukawa master ブランチが絶対安定してるなら、今度は release ブランチいらない感ある。で、どちらかというと release ブランチを安定させて master ブランチで開発すれば良い。そのほうが github とも親和性高い感ある。
2014-05-30 11:38:51
songmu
@songmu
@sonots @yosuke_furukawa 僕はまさしくそんな感じでやってましたねー。 ref. songmu.jp/riji/entry/201…
2014-05-30 11:44:06
hokaccha
@hokaccha
Webサービスの開発みたいにばんばんリリースしていくような場合は git flow は向いてないと思っている。GitHub flow くらいがちょうどいい
2014-05-30 11:51:47
Kazuyuki Honda
@hakobera
@sonots @songmu @yosuke_furukawa それはまさに github flow gist.github.com/juno/3112343
2014-05-30 11:53:47
そのっつ (Naotoshi Seo)
@sonots
@hakobera @songmu @yosuke_furukawa github-flow は master をすぐデプロイする点が違ってて、さらに省力化を測ってる感じありますね。
2014-05-30 11:58:06
songmu
@songmu
@hakobera 基本github-flowだけど、masterは直接deployせずに、前段にもうひとつリリース用のブランチ作って、そこに適宜マージしていく感じですね。
2014-05-30 11:59:19
Kazuyuki Honda
@hakobera
@sonots @songmu @yosuke_furukawa release ブランチも稀に作るんだけど、マージ漏れ、コンフリクトがつらいとかあって基本的には master にガンガンいってます。リリース日を調整したい場合は、master の本番への自動デプロイを止めてますね
2014-05-30 12:05:06
そのっつ (Naotoshi Seo)
@sonots
@hakobera @songmu @yosuke_furukawa サーバアプリは release ブランチ省いても良さそう感ありますね。すぐロールバックできるし。gfx氏のやつみたいにモバイルアプリだとリリースブランチあったほうが良さそう #まとめ
2014-05-30 12:08:01
hokaccha
@hokaccha
@hakobera master にマージしたら自動デプロイするフローで、master と feature を結合して問題ないかを確認したい場合はマージ前に master を rebase する感じですか？テストは当然回ってると思いますが目で確認した場合とか。
2014-05-30 12:18:12
Kazuyuki Honda
@hakobera
@hokaccha 基本的に細かくやってるからあんまりそういうニーズないんだけど、どうしてもの場合は検証用ブランチでmergeしてそこで確認してます。ブランチはHerokuに自動デプロイなので。詳細は弊社CTOのブログを参照 blog.madoro.org/mn/93
2014-05-30 12:29:29
hokaccha
@hokaccha
@hakobera あー、なるほど。すぐ消すリリースブランチわかりやすいですね。うちも Circle CI/Heroku なので Quipper 社の自動デプロイ丸パクリしようかなと思ってるところです。
2014-05-30 12:32:51