如何处理单个项目的多个代码版本

  • Mark Levison
  • 郑柯

2008 年 6 月 4 日

话题:敏捷DevOps架构文化 & 方法

一旦产品发布了第一个版本,你的团队将面临下面的困境——如何在继续发布新版本的同时维护第一个版本。对于这个问题,Target Process 公司的 CEO 兼创始人Michael Dubakov,在“是否应该在项目中采用并行方式进行发布和迭代?”这篇文章中分享了他们的经验。

在 Michael 的例子中,他打算对 1.0 版本进行修复,继续 1.5 版本的工作,并为 2.0 版本开发新功能。同一个项目的工作应该由同一个团队来完成吗?在这样的团队中,是否该让某些开发人员发布 2.0 版本,其他人从事 1.5 版本的工作,并让 Joe(具有牺牲精神的开发人员)挤出时间来修复 1.0 版本的重要问题?Michael 得出的结论是:让浪费最小化,而且不在 2.0 上进行开发。针对进行 1.5 版本开发的程序员,我们减少了他们需要同时处理的任务,并尽量拖延作决定的时间(到 2.0 版本开始的时候,一些现在看来 2.0 所必备的功能可能已经不再需要了)。

根据Steve Campbell的经验,这个问题最好的解决方式是:将所有的任务(包括所有的版本)放置在单独的 Sprint Backlog 中。这样一来,任何一个团队成员都可以选取一个任务(不管是哪一个版本),然后开始工作。Steve 继续讨论了这种情况下的分支策略:要么不要任何分支(采用运行时切换机制来区分不同的版本),要么只在重新开发组件的时候再做分支。

来自 Eclipse 软件系统公司的Matt Swaffer采用的方法与之迥异。他的团队不发布补丁程序,实际上他们要保持主干的稳定,如果修复了 bug,他们会邀请用户下载最新的版本。另外,他们还会为每一个版本打上标记,一旦发生严重的 bug 可以回溯到原来的版本进行修复。他们的终极目标是每周发布新版本。

说到基于同一个代码库发布多个产品的问题,《Implementation Patterns》的作者Kent Beck谈到一个例子:他参与了两个项目,团队需要支持七个客户。除了核心逻辑之外,每个项目都有大量的自定义代码。其中一个项目为每个客户保留了独立的代码库,每当有新客户时,他们会克隆一个“最新鲜”的分支,并继续进行开发。正如 Kent 所指出的,这样一来,他们被合并所带来的工作量淹没了。而另外一个项目中,交付给每个用户的是单独的二进制文件,这种方式保证每个客户执行的都是自己需要的代码。Kent 认为这两个项目关键的不同之处在于:

关键在于找到方法推迟关联。我发现从一开始就要定好原则——我们将使用独立的代码库。这种方式减少了一些设计上的选择,但是仍然留有很大余地。还有另一个重要的原则,在第一个案例中我们不介意有一些重复的代码,如果能够明确如何消除重复代码,我们愿意这么做,但现在还没有,我们仍然希望能找到清晰的解决方案。

最后来自N-BRAINJohn A. De Goes这样说:

分支是浪费的一种形式,我们的目标是消除分支。我们采用单独的代码库,只支持最近发布的一个版本,每次发布都强行推送给所有用户,并频繁发布(理想情况是,一次发布增加一个功能,或移除一个缺陷)。采用 SaaS 的方式实现起来会更简单。

查看英文原文: Handling Multiple Versions in a Single Project Team?

敏捷DevOps架构文化 & 方法