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

关于我的问题。在客户端UAT之后，我们经常让客户端说，他们很高兴能够发布一部分特性，而其他特性则希望在将来的版本中发布

我的问题是“如何发布2/3（三分之二）的功能”。 我想知道微软这样的大公司是如何应对这样的情况的。。 “对，我们只打算在Word的下一个版本中发布45/50最初提出的功能/修复，打包并发布”

假设下一版本中未发布的这5项功能已启动。。在发布版本的构建和部署中，如何忽略它们

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

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

---

--Lee

这通常是版本控制的一个功能，但根据项目的规模以及需要或不需要的变更集/修订的数量，这样做可能相当复杂

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

---

这种方法有几个优点，即您不必处理哪些功能/修复程序已合并，哪些功能/修复程序尚未合并，这取决于您如何实现配置，以及该功能是否在部署时完成，客户可以改变主意，而不必等到新版本才利用附加功能。

如果您事先没有考虑过这一点，那么很难做到这一点

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

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

决定如何组织对单个要素的工作。一种方法是将每个特性保留在其自己的分支上，只有在新特性准备就绪时才将其合并回主分支。这里的目标是使主分支始终几乎可交付。当特性分支不四处收集灰尘时，这是最简单的——也许每个程序员一次只能处理1或2个特性，并在它们准备好后立即合并它们

或者，您可以尝试从版本控制历史记录中挑选单个补丁。这是乏味且容易出错的，但是对于某些非常有纪律的开发团队来说，他们编写的补丁非常干净，只进行了一次完全的更改，这是可能的。您可以在Linux内核社区中看到这种类型的补丁。试着看看这种开发风格是什么样子的

如果您在始终保持主干“几乎可交付”方面遇到困难，您可能需要阅读一本关于敏捷编程的书，例如。如果您的新代码有很多缺陷，并且需要长时间的测试才能找到基本的逻辑错误，那么世界上所有的分支和合并都将是无用的

更新

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

如果客户机只需要一些已经工作的特性怎么办？这会让我有点担心，我想问他们为什么客户端只需要一些特性。他们对代码的质量感到紧张吗？我们是否构建了正确的功能？如果我们正在开发客户真正想要的功能，如果我们的主要分支总是可靠的，那么客户应该渴望得到我们实现的所有东西。因此，在本例中，我将首先努力查找流程中的潜在问题，并尝试修复它们

---

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

这让我想起了我在Borland申请项目经理职位时被问到的一个面试问题。问题的措辞有所不同——一个功能中存在一个在固定发布日期之前无法修复的主要缺陷——但我认为同样的方法也可以奏效：在未来的发布中删除这些功能的UI元素

当然，这是假设你想留下的功能对你想发布的其他功能没有影响。。。但是如果是这样的话，仅仅改变用户界面要比试图做出更剧烈的改变容易得多

---

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

这很容易，是否已经完成了：

从当前主线创建一个2/3版本分支

在2/3版本分支中，删除不需要的功能

稳定2/3释放分支

将版本命名为My Product 2.1 2/3

从2/3释放分支释放

回到主线的发展上来

---

我想我喜欢你关于每个新的主要功能都有一个分支的想法。。理论上。。除非我仍然希望人们经常登记，即使是到分行。由于我的CI将首先检查主干，您是否将CI设置在分支上