第3回 ブランチvs.フラグ | gihyo.jp

とっておきの変更 ソフトウェアをいつでもリリースできるようにしろと求める継続的デリバリの広まりにより、毎日のようにソフトウェアがリリースされるようになりました。早いうちからコードを野にさらせば、隠れた問題を前もって見つけることができるからです。 短いリリース間隔に身を置くと気づくことがあります。「⁠リリースできること」と「リリースしたいこと」は、必ずしも一致しないのです。たとえば大規模なビジュアルデザインの変更やとっておきの新機能を想像してみましょう。こうした粒度の大きい変更は、たとえ動作する、つまりリリース可能な状態でも、そのまま衆目にさらしたいとは限りません。期待を裏切らない形でお披露目したい、とっておきの変更があります。息を飲む新しい体験がもたらすユーザの驚きや喜びも、ソフトウェアにとっては大切な財産だからです。 とっておきの変更を仕上げるには時間がかかります。一方で、その仕上げが終

[at_yasu]

フラグだとDIとか使ってる場合は楽そうだけど、地のベタ書きだと大変そうだなぁ…

[peketamin]

DBマイグレーションがあるような機能変更はどうしてるんだろう。

[umai_bow]

へー

[t-wada]

フィーチャートグルの考え方を最初に知ったのは omo さんの連載だったけど、こんなに前のことだったんだなぁ…

[Untouchable]

継続的デリバリと「とっておきの変更」の開発を両立させる際に「ブランチ」か「フラグ」のどちらを使うか、それぞれの利点と欠点、またそれらを助けるツールの紹介も

[kana321]

　ブランチvs.フラグ

[hoisjp]

しばらく前の記事だけどfeature toggleあたりの良いまとめ。

[kshimizu1226]

リポジトリ戦略

[ngmy]

開発スピードと保守性とのトレードオフだな。

[raimon49]

継続的デリバリーにおけるアンチブランチ主義　いわゆる抽象化ブランチ

[tgk]

「「ブランチAがトランクにマージされたとしましょう。ブランチBの開発者には地獄が待っています」「フラグにこうした問題はありません。マージのように複雑さが一度に打ち寄せる危険が少ないのです」

[sgtakeru]

ふむー。フラグで機能切替か。最後の東京駅と新宿駅の比較がすっと理解できた。わかりやすい。

[mrkn]

べんりなものがいっぱい〜

[secondlife]

cookpad の chanko はフラグ、なるほど〜

[hiroomi]

"「リリースできること」と「リリースしたいこと」は，必ずしも一致しないのです。"

[ikeike443]

どちらにせよショートタームの開発である前提よね

[oppara]

第3回　ブランチvs.フラグ：Comparators―比べてみればわかること｜gihyo.jp … 技術評論社

[toshikaz55]

Comparators―比べてみればわかること：第3回　ブランチvs.フラグ #gihyojp

[amazedkoumei]

Branch By Abstraction をBBAと省略されたがゆえに脳内でババアと変換されて

[efcl]

ブランチとフラグモデル マージの難しさを持つフューチャーブランチと実験的なものをフラグで管理できるフラグ方式

[katzchang]

フラグではなくトグルと呼びたい

[akkun_choi]

フラグで管理。アンチブランチ主義