機能トグルと機能ブランチ
「機能切り替え」および「機能分岐」とは何ですか？それらの違いは何ですか？
長所と短所は何ですか？なぜ一方が他方より優れているのですか？
これに関してGoogleでいくつかの記事を見つけました。「機能切り替え」キャンプに参加する傾向がありますが、「機能切り替え」がすべての場合に適しているとは思いません。
機能トグルは、継続的インテグレーション/継続的デリバリー（CI/CD）チェーンで使用される方法論です（アジャイル/かんばんプロジェクト方法論）。基本的に、新しい機能を無効な状態で運用環境に送信し、管理コンソールで機能をオンにします（破損している場合はオフにします）。
機能ブランチ可能リリース方法論の一部であり、継続的インテグレーションチェーンに統合されています。機能ブランチで開発し、DEV/QAにブランチを展開し、認証を取得し、機能ブランチをトランクにマージしてから、トランクをSIT/UAT/PROD環境にプッシュできます。
このアプローチには長所と短所があります。機能の切り替えには、壊れた/暗いコードが実稼働するため、非常に厳しい規律が必要です。これは、管理者がこれを実行する方法を知っており、システム自動化ツール（Chef/Puppet/cfengineなど）を導入しているスタートアップやショップに最適です。Google、Facebook、LinkedIn、WordPress all deploy機能の切り替えとシステム自動化を使用した実稼働環境へ。
機能の切り替えを適切に行うための前提条件となる「技術」があります：継続的配信/展開、継続的統合、自動化された単体テスト、自動化された統合テスト、自動化されたストレス/パフォーマンステスト、システム自動化。これらが適切に用意されていない場合は、よりシンプルなリリース戦略（機能の分岐など）を検討してください。
これについてはブログで詳しく説明します： http://geekswithblogs.net/Optikal/archive/2013/02/10/152069.aspx
要するに、機能ブランチはより良い分離を提供しますが、遅延された統合とマージの痛みに対処する必要があります。トグルは継続的な統合を提供しますが、トグルをサポートするような方法でコードを設計/実装し、未完成の機能コードが生産に悪影響を与えるリスクを導入する必要があります。
両方のブランチとトグルを一緒に使用できます（これらは相互に排他的ではありません）。各シナリオでどちらを使用するかを決定する限り、私の考えでは、以下が当てはまらない限り、トグルをデフォルトの選択にする必要があります。
- トグルの背後にある機能を隠すのは難しい
- 徹底的なテストが行われていないアプリケーションの領域に潜在的な影響がある
これらの条件のいずれかが当てはまる場合、トグルの代わりに機能ブランチを使用するでしょう。
機能の切り替えには、壊れた/暗いコードが本番に移行するため、非常に厳しい規律が必要です。
私はElectrawnに同意します。6年前から機能の分岐を使用してきました。なぜなら、私たちの場合、前提条件がないからです。
また、「Toogle戦略」は、Feature Branches Strategy（Merging）に費やされた努力を別の瞬間に移すことを理解することも重要です。
http://martinfowler.com/bliki/FeatureToggle.html
保留中の機能が本番環境に組み込まれたら、トグルを廃止することが非常に重要です。これには、構成ファイルの定義とそれらを使用するすべてのコードの削除が含まれます。そうしないと、トグルの山ができてしまい、誰も使用方法を思い出せません。私が聞いた記憶に残る例では、十分なコマンドラインスイッチを処理するために、Linuxカーネルを特別に再コンパイルする必要がありました。
注：誰かがファイルを開いて編集する場合、SCMの原則に従うと、コードが破損する可能性があります。
ですから、私の観点では、「すべてのケースでより良い選択」を信じていません。なぜなら、それはあなたのチームの文化とテストカバーがあるかどうかに依存するからです。
まあそれは非常に論争的な質問です。
私は今でも私の場合、機能ブランチ戦略を好んでいます。 SCMのベストプラクティスを維持し、ロードマップを計画すると、マージプロセスは簡単な方法になる傾向があります。これらの年の間に、私は多くの人々がマージプロセスについて不平を言うのを聞いたが、多くの場合、マージの問題は私の経験で同じであり、「コミュニケーションは失敗する」:)
不正確な答えで申し訳ありませんが、SCMのより良い選択のこの主題の周りには人間の側面があると思います。