按功能划分 - 优点/缺点？

Question

我目前正在从事一个项目,在这个项目中,分支和合并从一开始就没有起到很好的作用.为了改变这种状况,我们一直在讨论各种不同的方法.我假设每个人都有自己的哲学关于如何做这种事情,所以它似乎也在这里.

我们一直在谈论的一件事是按功能分支.我们碰巧对这种特殊的方法有什么不同的看法.

你有过这样做的经验吗？它运作得好吗？你有问题 - 什么样的问题？

我知道这个问题确实没有正确的答案,但我发现听到全世界其他开发人员的意见非常有趣,而stackowerflow似乎是一个很好的选择.

Answer 1

我们使用分支功能,它对我们非常有效.最大的优势是功能团队知道他们正在进行的工作不会影响其他功能团队,直到新功能集成(在我们的案例中为Main).

当我们完成一个新功能(并且分支已合并到Main)时,我们将分支移动到Branch History文件夹中.这使得开发人员需要将分支(文件夹)的数量保持在最小值.

在我们的例子中,没有人在主分公司工作.所有开发都在功能分支中完成.初始开发(在第一次发布到生产之前)在开发分支中完成.在第一次发布到生产之后,所有开发都在新的功能分支中完成.

Answer 2

如果您有一个中小型团队,那么当您不需要完全分支隔离时,请避免使用额外的分支...尤其是如果您的开发团队的文化反对分支和正确合并.也许,以换取较少的分支机构,以保持确保合并的做法是遵循宗教谁是允许做合并所有的开发人员.Shelvesets(在TFS中)和短期特征分支是最小化合并开销和相关风险的好方法.

细节

这是我发现的平衡生产力与版本控制安全性的模式(适用于~25个开发人员和~3个测试人员的团队):

1. 在同一分支中工作:处理松散耦合或不相关代码的开发人员可以相对安全地直接在相同的Dev(或"Integration")分支中工作.错误修正和非破坏性更改非常适合这种情况(较大的主要回归风险会影响其他开发人员).持续集成构建和门控构建是两种最佳实践,可以降低在同一分支中工作的许多开发人员的风险. 切换注意:功能切换可用于进一步避免需要分支,但确保测试/维护切换行为的开销不比使用分支更具风险.

2. Shelvesets:使用版本控制系统的功能在开发人员特定的原型分支中保存挂起的更改.签入TFS(Team Foundation Server)的开发人员可以使用shelvesets而不是个人分支(或许多微功能/任务分支),如果他们是唯一需要在签入集成/ dev分支之前开发和测试该功能的人员.我相信其他版本控制系统具有类似的结构 ANTIPATTERN:本地工作空间自动为每个开发人员提供临时隔离......但是开发人员需要经常/每天在源代码管理中的某个位置检查他们的更改,以防止丢失当地的天数+的风险只有工作.)

3. 短期分支:当您确实需要一个分支进行隔离时(例如多个开发人员需要处理的突破性功能),那么创建短期功能分支是一个很好的方法.我建议使用分支命名约定,以保持分支使用定义良好且随着时间的推移是唯一的.

上述工作流程的主要优点是可以最大限度地减少合并税(将前向/后退(合并向下/向上)整合的时间),而不是开发直接提高客户幸福感的功能.

示例场景:新的"酷"功能将破坏现有功能并构建直到完成.它还需要2个以上的开发人员在相同的代码库上进行协作(取消使用Shelveset的选项).开发人员为"​​酷"创建名为Cool1的分支,然后开发和集成测试第一个版本的功能.开发者所有者负责每天合并父级更改(每周绝对最多).确认准备好合并(父合并做子(FI),所有UT和核心验收测试运行并仍然通过).合并到父(RI),然后确认在父分支中工作(所有UT和核心验收测试通过),然后删除Cool1功能分支(清理).
合并到dev/integration分支后,更彻底地测试Cool功能.(测试资源是有限的,因此避免每个分支的完整测试环境.)Cool的错误修正和战术增强/重构将直接在Dev分支中完成(当分配dev需要很多天到localy dev/test之前使用shelvesets).如果稍后需要Cool的主要(多开发人员)返工,那么创建一个新的Cool2分支.

TFS2010移动/重命名注意: TFS 2010移动和重命名行为已更改(从TFS 2008)以进行移动,Renames ="分支到新名称/位置,然后将原始项目标记为已删除".这意味着如果您不希望在源代码管理器\ Dev \中看到它们而不是将分支移动到其他文件夹,则应该删除非活动功能分支.这也意味着启用查看已删除文件夹的开发人员将始终将这些已删除(或移动或重命名)的短期分支视为"鬼",这些分支可能会变得混乱.(这就是你可以查看历史记录或取消删除已删除项目的方法.)

Answer 3

功能分支的替代方案是功能切换（即代码中可以使功能可用或不可用的开关）。它们在这方面确实很有用。它们可以允许开发和部署新功能，但只有在切换......良好切换（甚至是一个词）时才可用。我想这就像整个谷歌实验室的想法。

这里需要注意的一点是，如果在开发过程中没有仔细考虑和测试，这些切换本身也可能导致戏剧性的后果。您实际上增加了需要执行的测试量，以了解启用和禁用功能时情况如何。如果您正在开发多个功能，那么您需要了解它们如何与启用/禁用状态的各种组合进行交互。

话虽如此，如果做得好，它们也会带来巨大的好处。您可以向某些用户（高级用户或该功能的拥护者等）发布某个功能，而不会影响所有人。如果它被认为引起问题，则可以通过更改数据库记录中某些配置元素的存在来将其关闭。

一旦给定的功能被认为已通过测试，建议删除切换开关并使其成为整个应用程序的一部分。

话虽如此，我不认为功能分支不好，但它确实依赖于每个人都理解源代码控制和合并的概念，并确保分支不会与主分支过于脱节，从而导致一种巨大的 OMG 类型合并。

我最近参加了 Thoughtworks 主办的一次会议，马丁·福勒 (Martin Fowler) 讨论了这个主题。演讲的重点是持续交付以及这如何帮助克服缓慢且有风险的部署。请参阅http://www.thoughtworks.com/events/thoughtworks-continuous-delivery-devops或搜索连续交付以获取更多信息。