功能切换与功能分支

Question

什么是“功能切换”和“功能分支”，它们之间的区别是什么？

好处和坏处是什么？为什么一种比另一种更好？

我在Google上找到了一些关于这方面的文章，我倾向于“功能切换”阵营，但我不相信“功能切换”在所有情况下都是更好的选择。

Answer 1

功能切换是在持续集成/持续交付(CI/CD)链中使用的方法(敏捷/看板项目方法)。基本上，您将新特性以禁用状态发送到生产环境，然后在管理控制台中打开该特性(如果发现该特性已损坏，则将其关闭)。

功能分支可以是发布方法的一部分，并集成到持续集成链中。您可以在功能分支中进行开发，将分支部署到DEV/QA，获得认证，将功能分支合并到主干，然后将主干推送到SIT/UAT/PROD环境。

这种方法既有优点也有缺点。功能切换需要非常严格的纪律，因为破碎/黑暗的代码正在投入生产。这对于初创公司和商店来说是很棒的，因为他们的管理层知道如何做到这一点，并且有适当的系统自动化工具(Chef/Puppet/cfengine等)。LinkedIn和WordPress都使用功能切换和系统自动化部署到生产环境中。

要正确地进行特性切换，有一些先决条件“技术”：持续交付/部署、持续集成、自动化单元测试、自动化集成测试、自动化压力/性能测试、系统自动化。如果你还没有准备好这些，考虑一个更简单的发布策略(例如特性分支)。

Answer 2

我在我的博客上对此进行了深入的讨论：http://geekswithblogs.net/Optikal/archive/2013/02/10/152069.aspx

简而言之，功能分支将为您提供更好的隔离，但需要您处理延迟集成和合并的痛苦。toggles为您提供持续集成，但要求您以支持Toggles的方式设计/实现代码，并引入未完成的功能代码可能对生产产生负面影响的风险。

您可以同时使用分支和切换(它们不是互斥的)。至于决定在每个场景中使用哪一个，我的想法是切换应该是默认选择，除非满足以下条件：

• 难以隐藏切换
• 背后的功能对未进行彻底测试的应用程序区域有潜在影响

如果这两个条件中的任何一个为真，我可能会使用功能分支而不是切换。

Answer 3

功能切换需要非常严格的纪律，因为崩溃/黑暗的代码正在投入生产。

我同意Electrawn，我已经使用特性分支6年了，因为在我们的例子中，我们没有pre需求。

同样重要的是要理解"Toogle策略“将花费在功能分支策略(合并)上的工作转移到另一个时刻。

http://martinfowler.com/bliki/FeatureToggle.html

一旦挂起的特性在生产中稳定下来，停用切换是非常重要的。这涉及到删除配置文件上的定义以及使用这些定义的所有代码。否则，你将得到一堆没有人记得如何使用的切换。在我听说过的一个令人难忘的例子中，它需要对linux内核进行特殊的重新编译，以处理足够的命令行开关。

注意:遵循SCM原则，如果任何人打开和编辑一个文件，它可能是被破坏的代码。

因此，在我看来，我不相信“在所有情况下都是更好的选择”，因为这取决于你的团队的文化，以及你是否有测试封面。

嗯，这是一个非常有争议的问题。

在我的例子中，我仍然更喜欢功能分支策略。保持SCM最佳实践并规划路线图，合并过程往往是一种简单的方法。在这一年里，我听到很多人抱怨合并过程，但在大多数情况下，合并的问题在我的经验中是相同的，“通信失败”:)

很抱歉回答得不准确，但我认为在SCM中关于这个主题有一些人类方面的更好的选择。