如何发布可交付成果的子集？

Question

关于我在accidentally-released-code-to-live-how-to-prevent-happening-again的问题。在客户端UAT之后，我们经常会有客户端表示，他们很乐意发布一组特性，而其他功能则希望在将来的版本中发布。

我的问题是“如何发布2/3 (2/ 3)的特性”。我感兴趣的是像微软这样的大公司如何处理这样的情况。“是的，我们只会在下一个版本的Word中发布最初提出的特性/修复的45/50版本，打包并发布出来。”

假设在下一个版本中没有发布这5个特性，已经启动了。如何在发布版构建和部署中忽略它们？

如何发布2/3的开发功能？

如何发布可交付成果的子集？

--李

Answer 1

如果你事先没有想过这件事，那就很难做到。

但在未来，你可以这样做：

1. 获得一个真正的版本控制系统，对分支和合并都有很好的支持。在历史上，这意味着类似于git或Mercurial，因为Subversion的合并支持非常弱。( Subversion团队最近一直在改进他们的合并支持。)在Windows方面，我不知道什么VC工具最适合这样的东西。
2. 决定如何组织关于个人特征的工作。一种方法是将每个特性保留在自己的分支上，并且只有在新特性准备就绪时才将其合并回主分支。这里的目标是保持主要分支几乎在任何时候都可运输。这是最简单的，当特性分支不无所事事的时候--也许每个程序员一次只能处理一个或两个特性，并在它们准备好之后立即将它们合并？

或者，您可以尝试从版本控制历史记录中选择单独的修补程序。这是乏味和容易出错的，但对于某些纪律严明的开发团队来说，他们可能会编写非常干净的补丁，进行精确的1次完全更改。在Linux内核社区中可以看到这种类型的修补程序。试着看看Linux2.6gitweb上的一些补丁，看看这种开发风格是什么样的。

如果您在任何时候都无法保持主干“几乎可移植”，您可能想读一本关于敏捷编程的书，比如极端编程解释。如果您的新代码非常错误，并且需要长时间的测试才能找到基本的逻辑错误，那么世界上所有的分支和合并都将是无用的。

更新

特性分支是如何与持续集成一起工作的？一般来说，我倾向于在每次签入之后构建特性分支，就像主分支一样，我希望开发人员每天或多或少地提交。但更重要的是，我试图将特征分支合并到主要分支，非常积极--一个为期两周的特征分支会让我非常非常紧张，因为这意味着有人正生活在自己的小世界里。

如果客户只需要一些已经在工作的功能呢？这会让我有点担心，我想问他们为什么客户机只需要一些功能。他们对代码的质量感到紧张吗？我们正在建立正确的特征吗？如果我们正在开发客户真正想要的特性，而且如果我们的主要分支总是可靠的，那么客户机应该渴望得到我们已经实现的所有功能。因此，在这种情况下，我首先要努力寻找我们的过程中的潜在问题，并试图修复它们。

然而，如果有一些特殊的蓝月亮的原因，这一要求，我基本上会创建一个新的主干，重新合并一些分支，和樱桃挑选其他补丁。或者禁用一些UI，就像其他海报建议的那样。但我不会养成这种习惯的。

Answer 2

这让我想起了我在博兰申请项目经理职位时遇到的一个面试问题。在这里，问题的措辞不同--在一个不能在固定发布日期之前修复的特性中，有一个主要的错误--但我认为同样的方法是可行的:为将来的版本删除特性的UI元素。

当然，这假设您想要排除的特性不会影响到您想要发送的其他功能。但是，如果是这样的话，仅仅更改UI比尝试进行更剧烈的更改更容易。

实际上，我认为您要做的是将代码进行发布，然后在该分支上进行UI删除。

Answer 3

它通常是一个版本控制功能，但这样的操作可能会非常复杂，这取决于项目的大小以及您必须将多少更改集/修订分类为所需的或不需要的。

我过去使用过的另一种但相当成功的策略是将这些特性本身配置为可配置的，并将它们作为禁用的特性部署到未完成的特性或不想使用某些功能的客户端。

这种方法有几个优点，因为您不必权衡哪些特性/修复已经合并，哪些修复没有合并，取决于您实现配置的方式，如果特性在部署时完成，客户端可以改变他们的想法，而不必等到新版本才能利用附加的功能。