「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog

はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。 戦略 ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時本番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする 機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースする なぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。 失敗パターンその1: 巨大PRパターン 失敗パターンその2: 新機能リリースブランチパターン 失敗パターンその1: 巨大PRパターン 新機

[shiba_yu36]

社内勉強会発表内容を公開しました！

[xlc]

そもそもなぜそんなにコンフリクトするのか考えた方がいいんじゃないの。①設計が悪く機能がきれいに分かれていない、②1つのシステムに関わる人数が多すぎる

[PEEE]

masterを適宜featureにmergeするんじゃダメなんだろうか。

[hasegawatomoki]

「設計が悪い」のはあるかもしれないけど、完璧な設計など世の中には無いし、それを受け入れた上でどうやって前進するか、という話だね。

[Sixeight]

よくマージできずにプルリクが連なっていって先頭の方で修正が入ることで死亡する

[suzan2go]

思ったより反対の人が多いのにビビった

[kibitaki]

バカヤロウこれは戦術だ！とミリオタが多いSIerでは怒鳴られるな。

[tettekete37564]

イマイチメリットがハッキリしない。どれも原因は「超コンフリクト」と言っているが「細かくマージする」は運用でカバーする方法にしか聞こえないので根本的な設計(コード・分業の両方)に正しい解決方法がありそう

[laiso]

よくやるオススメ。メインの作業をしつつパッチ袋から1つ進捗を取り出して投げるような感覚。ネイティブappの場合よりフロント側で隠すのに苦労した。

[d0i]

やっぱりいらないやってなったときどうやって捨てるのかな。

[adwd118]

こういうのやりたい

[yujiorama]

どうしてもコミットを分割してくれない人がいるときに役立ちそう

[SWIMATH2]

フラグ分けわかる

[dabits]

「ユーザに新機能が見えないように工夫してガンガン本番へリリースする」新しいアプローチ。どこかのプロジェクトで試行してみたい。

[ravelll]

めちゃいい

[k-holy]

分かるし、やってる。特にDBへのカラムの追加を伴う場合は既存機能に影響出ない形で先行してやる。1人開発だけど。

[efcl]

Gitのfeature branchのマージ戦略について

[futeshi]

masterを適宜featureにmergeするだと、リリース後に他の人が大量にコンフリクトするのが問題になりそうだと思いました

[nilab]

「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog

[konisimple]

これはアリだな。少人数なのでコンフリクトはしっかりmasterから mergeしてれば割と大丈夫だけど、PRが煮詰まってきたときに小さな修正が増えて、レビュアーが辛い問題が解消できそう

[mactkg]

すばやくどしどしやっていくぞみたいな方向だと落としどころとして良さそうに思った！ 割と同じブランチでだらだら作業しがち…

[terazzo]

共通メソッドの話は下のレイヤーから機能別にcommitすれば回避できそう

[mas-higa]

ここは通らないからOK ... これを許してくれるプロジェクトならどんなに楽か。

[peller]

featureブランチに携わるメンバーに一時手を止めてもらってrebaseする派。mergeするとcommitの流れが汚くなっちゃうのでね。

[Dai_Kamijo]

大規模マージのつらさに対する代替選択肢としてはありかも知れない。『「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました』 — Takuma SHIRAISHI (@ts7i) August 8, 2017 from Twitter https://twit

[kakku22]

非公開リリースは凄く良くてたまに使ってる．リリースされないプルリクが残ることも無くて cherry-pick で頑張ることもなくなる

[june29]

わかりすぎる…。

[uskey]

作業分担とか実装順序の依存関係とか設計がきちんとしてたら必要なさそうだけど、そんなことない現実の開発環境だと有効な手の１つだと思う。細かくマージする以上細かくレビュー出来るのもメリットか。

[satohu20xx]

見えないとはいえ新しいコードが含まれるとそれはバグを生むものなので、できれば動くはずがないコードは入れたくないよね。

[atwata]

フィーチャートグルというらしい

[naga_sawa]

新バージョンリリース後は旧機能の掃除コミットが続く感じになるんだろうか

[gomayumax]

社内ツールぐらいだったらすぐに試せそう(・∀・)やりたい

[holyshared]

こういうのだいたいリリースまじかになってフラグ消し忘れがあるんだよなぁ。ネイティブアプリのサーバーの場合、複数バージョン意識しないと行けないから消せない場合あるし

[takuji31]

基本的にこのやり方でよくって、はてなブックマークのアプリでもこの手法でやってる。 唯一使えないのは大きめのリファクタリングを行う時で、そういう場合はやむを得ず集約branch作ったりする。

[Pasta-K]

似た感じでやってる

[wkubota]

ブランチ戦略のアプローチ方法として参考になった。選択肢の一つにさせてもらおう。

[yamitzky]

ブコメ見ると否定は多くて不思議

[dowhile]

フロント側バック側を変えるような大きな改変がやりにくそう

[luccafort]

例えばA機能を実装しようとしたときに先にB機能を実装したことでA機能の意味がほぼなくなってしまってissue自体をCloseされたら場合各実装をrevertしていくのだろうか？あと入れ替えミスとかが怖い。