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

Question

继我accidentally-released-code-to-live-how-to-prevent-happening-again的问题。在客户端UAT之后，我们经常让客户说他们很高兴能够发布一部分要素，而不是他们想要在未来的版本中发布。

我的问题是“你如何发布你的功能的2/3（三分之二）”。 我会对像微软这样的大公司如何处理像......这样的情况感兴趣。 “我们只会在下一版本的Word中发布最初提出的功能/修复的45/50，将其打包并发送出去”。

假设下一个版本中没有发布这5个功能已经启动了..你怎么能在发布版本和版本中忽略它们？部署？

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

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

- 李

Answer 1

如果你没有事先考虑过这个问题，那就太难了。

但将来，您可以采取以下措施：

1. 获得真正的版本控制系统，对分支和合并都有很好的支持。从历史上看，这意味着像git或Mercurial，因为Subversion的合并支持非常弱。 （Subversion团队最近一直在努力改进他们的合并支持。）在Windows方面，我不知道哪种VC工具最适合这样的事情。

2. 决定如何组织各个功能的工作。一种方法是将每个功能保留在自己的分支上，并在新功能准备好时将其合并回主分支。这里的目标是始终保持主分支几乎可以发送。当功能分支没有围绕着收集灰尘时这是最简单的 - 也许每个程序员一次只能处理1或2个功能，并在它们准备好后立即合并它们？

或者，您可以尝试从版本控制历史记录中挑选单个补丁。这是繁琐且容易出错的，但对于某些非常有纪律的开发小组来说，编写非常干净的补丁可以完全实现1次完全更改。您在Linux内核社区中看到了这种类型的补丁。试着看some patches on the Linux 2.6 gitweb看看这种发展方式是什么样的。

如果您在任何时候都无法保持行李箱“几乎可以发送”，您可能需要阅读有关敏捷编程的书籍，例如Extreme Programming Explained。如果您的新代码往往非常错误并需要长时间的测试才能找到基本的逻辑错误，那么世界上所有的分支和合并将毫无用处。

<强>更新

功能分支如何与持续集成协同工作？通常，我倾向于在每次签入后构建功能分支，就像主分支一样，我希望开发人员能够提交更多 - 或 - 每天少。但更重要的是，我试图将功能分支非常积极地合并到主分支 - 一个2周大的功能分支会让我非常非常紧张，因为这意味着有人在他们自己的小世界中生活。

如果客户只想要一些已经正常工作的功能怎么办？这会让我有点担心，我想问他们为什么客户只想要一些的功能。他们对代码的质量感到紧张吗？我们正在构建正确的功能吗？如果我们正在处理客户端真正想要的功能，并且我们的主分支始终是可靠的，那么客户端应该渴望获得我们实现的所有内容。所以在这种情况下，我首先会努力寻找我们流程的潜在问题并尝试解决它们。

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

Answer 2

这让我想起了很多关于我在申请项目经理职位时在Borland被问过的面试问题。问题的措辞有所不同 - 在一个功能中存在一个主要错误，在固定发布日期之前无法修复 - 但我认为相同的方法可以工作：删除未来版本的功能的UI元素。

当然，这假设您想要发布的功能对您想要发布的功能没有任何影响......但如果是这样的话，只需更改UI比尝试进行更大幅度的更改更容易

在实践中，我认为你会做的是将代码分支发布，然后在该分支上删除UI。

Answer 3

它通常是版本控制的功能，但是执行类似的操作可能会非常复杂，具体取决于项目的大小以及您需要将多少个更改集/修订分类为期望或不需要。

我过去采用的一种不同但相当成功的策略是使功能本身可配置，只是将它们部署为未完成功能的禁用或者不想使用某些功能的客户端。

这种方法有几个优点，因为您不必处理已合并但尚未合并的功能/修补程序，并且取决于您如何实施配置以及部署时功能是否已完成，客户可以改变主意，而不必等到新版本才能利用其他功能。

Answer 4

这很简单，就是这样做的：

1. 从当前主线创建2/3版本分支。
2. 在2/3版本分支中，删除不需要的功能。
3. 稳定2/3版本分支。
4. 将版本命名为My Product 2.1 2/3。
5. 从2/3发布分支发布。
6. 返回主线发展。