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

コメント

Tsuyoshi CHO @tsuyoshi_cho 2014年5月31日
リリース前を管理する(というと乱雑だけど、それをdevelopで集約する)必要がない場合、かなあ、規模と速度、修正とかの影響の出方などプロダクト/言語/ライブラリでかわる気がする。
ログインして広告を非表示にする
ログインして広告を非表示にする