在accidentally-released-code-to-live-how-to-prevent-happening-again 进一步回答我的问题。在客户 UAT 之后，我们经常让客户说他们很高兴发布部分功能，而他们希望在未来的版本中发布其他功能。
我的问题是“您如何发布 2/3（三分之二）的功能”。 我会对微软等大公司如何处理类似情况感兴趣。 “是的，我们只会在下一个 Word 版本中发布 45/50 最初提出的功能/修复，打包并发布”。
假设下一个版本中未发布的这 5 个功能已经启动..您如何在发布构建和部署中忽略它们？
您如何发布 2/3 的开发功能？
如何发布可交付成果的子集？
--李
【问题讨论】：
标签： build-process release specifications release-management
如果你事先没有考虑到这一点，这很难做到。
但在未来，您可以通过以下方式让自己做到这一点：
获得真正的版本控制系统，对分支和合并都有很好的支持。从历史上看，这意味着像 git 或 Mercurial，因为 Subversion 的合并支持非常弱。 （不过，Subversion 团队最近一直在努力改进他们的合并支持。）在 Windows 方面，我不知道哪种 VC 工具最适合这种情况。
决定如何组织各个功能的工作。一种方法是将每个功能保留在自己的分支上，并且仅在新功能准备好时将其合并回主分支。这里的目标是始终保持主分支几乎可交付。当特性分支不坐在那里收集灰尘时，这是最简单的——也许每个程序员一次只能处理 1 或 2 个特性，并在它们准备好后立即合并它们？
或者，您可以尝试从版本控制历史记录中挑选个别补丁。这是单调乏味且容易出错的，但对于某些非常有纪律的开发团队来说，他们编写非常干净的补丁来进行 1 个完整的更改可能是可能的。您会在 Linux 内核社区中看到这种类型的补丁。试试看some patches on the Linux 2.6 gitweb，看看这种开发风格是什么样子的。
如果您无法始终保持“几乎可交付”的行李箱，您可能需要阅读有关敏捷编程的书籍，例如 Extreme Programming Explained。如果您的新代码往往有很多错误并且需要长时间的测试才能发现基本的逻辑错误，那么世界上所有的分支和合并都将毫无用处。
更新
特性分支如何与持续集成一起工作？ 一般来说，我倾向于在每次签入后构建特性分支，就像主分支一样，我希望开发人员提交更多或 -每天少。但更重要的是，我尝试非常积极地将特性分支合并回主分支——一个 2 周大的特性分支会让我非常非常紧张，因为这意味着有人生活在他们自己的小世界里。
如果客户只想要一些已经工作的功能怎么办？这会让我有点担心，我想问他们为什么客户只想要一些的特征。他们对代码的质量感到紧张吗？我们是否在构建正确的功能？如果我们正在开发客户真正想要的功能，并且如果我们的主分支总是可靠的，那么客户应该渴望得到我们已经实现的一切。所以在这种情况下，我会首先努力寻找我们流程的潜在问题并尝试修复它们。
但是，如果这个请求有什么特殊的千载难逢的原因，我基本上会创建一个新的主干，重新合并一些分支，然后挑选其他补丁。或者禁用一些用户界面，正如其他海报所建议的那样。但我不会养成这样的习惯。
【讨论】：
这让我想起了我在申请项目经理职位时在 Borland 被问到的一个面试问题。问题的措辞不同——一个功能存在一个重大错误，在固定的发布日期之前无法修复——但我认为同样的方法可以奏效：为未来版本删除功能的 UI 元素。
当然，这假设您想要遗漏的功能与您想要发布的其余功能没有任何影响......但如果是这种情况，只需更改 UI 比尝试进行更剧烈的更改更容易.
实际上，我认为您会做的是将代码分支以进行发布，然后在该分支上删除 UI。
【讨论】：
它通常是版本控制的功能，但是根据项目的大小以及您必须将多少变更集/修订分类为所需或不想要的，执行类似的操作可能会非常复杂。
我过去采用的一种不同但相当成功的策略是使功能本身可配置，并且仅将它们部署为禁用，以用于未完成的功能或还不想使用某些功能的客户。
这种方法有几个优点，您不必纠结哪些功能/修复已合并和尚未合并，并且取决于您实施配置的方式以及该功能是否在部署时完成，客户可以改变主意，而不必等到新版本发布即可利用附加功能。
【讨论】：
这很简单，已经做到了：
【讨论】：