Handling Multiple Versions in a Single Project Team

原作 ：Mark Levison [英文原文:http://www.infoq.com/news/2008/06/multiple_versions ]
翻译 ：oRbIt

    产品的第一个版本发布出去以后，你和你的团队就必须面临一个进退两难的局面－－如何在维护已经发布的版本的基础上继续开发下一个版本。针对这个问题，Michael Dubakov（Target Process的创建者和CEO）在他的文章《Should We Have Parallel Releases and Iterations in a Project?》中总结了一些经验。

    在文章举出的例子中，Michael需要修正1.0版本的BUG，同时还要继续开发1.5版本以及为2.0而设计的新的特性。是否存在一个需要对付整个项目的团队？在这个团队中安排一些人员开发新的2.0版，另一些人开发1.5版，并且让joe，一个有牺牲精神的开发人员，抽出一些时间解决1.0版遇到的棘手问题？对此，Michael的结论是不要四面出击，为了减少浪费，停止2.0的开发，所有的开发人员用在1.5版本的开发，因为现在看来2.0版本急需的一些特性到真正需要发布2.0版本的时候就可能变得不是那么重要了。

    对这个问题Steve Campbell的解决方案是将所有的工作（包括所有版本）集中到一个 Sprint Backlog中（译者注：Sprint Backlog是敏捷软件开发模型：SCRUM模型的一个概念，就是一个sprint周期内所需要完成的任务列表），每一个团队成员只要从中领到一个任务并完成就行了。Steve还认为在这种情况下使用分支的策略就是要么完全不使用分支（软件在运行期间切换版本），要么只对某个组件拉分支。

    来自Eclipse Software Systems Inc的Matt Swaffer则提出了另一个完全不同的方法，他的团队从不发布任何补丁，取而代之地是集中全部人员维护一个稳定的主干分支，当遇到BUG时，只需要引导客户下载一个最新的构造版本就行了。除此之外，他们对每个发布版本都打上标签，BUG的修改针对特定的标签。他们的最终目标是每周的构造都是一个可发布的版本。

    现在回到前面说得在一个代码流上维护多个产品的问题，《Implementation Patterns》一书的作者Kent Beck谈到过两个他所参与的项目，每个项目都是除了核心逻辑之外还有大量的定制代码。在第一个项目中他们为每个客户维护一份互相独立的代码，对每一个新客户他们都从当前最新的分支上“克隆”一份代码，并在其基础上进行开发。其结果正如Kent所说的那样，他们被这些不同的（版本的）组合压垮。在另一个项目中他们提供给每个客户一个统一的二进制版本，针对不同客户的定制代码只在生成版本的时候才包括进来。Kent认为二者的关键区别在于：

    二者的不同之处就是是否找到一种方法推迟绑定。我的发现就是这种不同始于对原则的选择，第一个原则就是－－我们使用一个基础代码，这可能需要删除一些设计选项，但是公共部分都被保留下来。另一个重要的原则就是是否介意有重复代码，在第一种情况下我们不介意是否有重复代码。如果我们很明确地知道如何消除重复代码，我们就去做，但是我们更愿意等待，直到它变得更清晰为止（译者注：就像第二个项目那样，直到生成版本的时候才决定哪些代码需要被包含进版本中）。
   
    最后，John A. De Goes（来自N-BRAIN）说：分支都是某种形式的浪费，我们的目标就是消除它们，将它们合并到一个代码流中，只对最新发布的版本提供支持。版本发布应该尽可能的快，理想情况下是对每个特性或缺陷（修正）发布一个版本，所有这些都随着SaaS而简化（译者注：SaaS，Software as a Service，软件即服务）。