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,软件即服务)。

阅读更多
上一篇CHM转PDF工具综述
下一篇TabSiPlus发布没有时间限制的版本
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭