45

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

优缺点都有什么？为什么一个比另一个好？

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

4

3 回答 3

52

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

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

这种方法有利有弊。功能切换需要非常严格的纪律，因为损坏/暗码正在投入生产。这对于管理层知道如何实现这一目标并拥有系统自动化工具（Chef/Puppet/cfengine 等）的初创公司和商店非常有用。Google、Facebook、LinkedIn、WordPress 都使用功能切换和系统自动化部署到生产环境.

有一些先决条件“技术”可以正确地进行功能切换：持续交付/部署、持续集成、自动化单元测试、自动化集成测试、自动化压力/性能测试、系统自动化。如果您没有这些，请考虑更简单的发布策略（例如功能分支。）

于 2013-10-17T18:44:29.507 回答
24

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

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

您可以同时使用分支和切换（它们不是相互排斥的）。至于决定在每种情况下使用哪一个，我的想法是切换应该是默认选择，除非以下情况属实：

  • 难以隐藏切换背后的功能
  • 对没有经过全面测试的应用程序区域有潜在影响

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

于 2013-10-17T22:21:26.160 回答
5

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

我同意 Electrawn，我已经使用功能分支 6 年了，因为在我们的案例中，我们没有预先要求。

同样重要的是要了解“Toogle 策略”将在功能分支策略（合并）中花费的精力转移到另一个时刻。

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

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

注意：遵循 SCM 原则，如果有人打开并编辑文件，则可能是代码损坏。

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

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

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

抱歉，答案不准确，但我认为在 SCM 中，围绕这个主题有一些人类方面的更好选择。

于 2013-10-17T19:33:07.193 回答