利用“抽象分支”做增量式大规模软件改造

很多开发团队通常严重依赖于版本控制系统的分支功能。分布式版本控制系统让分支操作更加方便。然而,在《持续交付》一书中描述的很多非常规言论中,就有一条是:“使用分支,你就无法做持续集成”。根据定义,如果你有代码在某个分支上,那就没有集成。有一种很常见的情况,会让人很自然地想到利用版本控制工具的分支功能:那就是“对应用程序进行大规模改造时”。然而,还有一种替代这种真实分支的做法,技术上叫做“抽象分支(Branch by Abstraction)”。

抽象分支:在主干上进行以增量方式对软件进行大规模改造的一种模式。

Paul Hammant在2007年就提到过用这种方式把OR mapping的方案从Hibernate切换到iBatis(详见这里)。同样,我曾经工作的一款商业产品(持续集成与敏捷发布管理平台 Go)则从iBatis改到了Hibernate,这已经是两年前做的事情了。我们也把产品的UI层慢慢地从“使用Velocity和JsTemplate”转移到了“JRuby on Rails”上。

这两种变化都是慢慢地增量式地完成的,在改变的同时,也做新功能的开发,但这并不妨碍我们每天向Mercurail的版本库主干上提交数次代码,甚至在切换过程中做了数次正式发布。我们是如何做到的呢? Continue reading 利用“抽象分支”做增量式大规模软件改造

配置与发布管理成熟度模型1.0版

在过去多年的持续集成咨询经历中,最常听到的一个问题是:如何来评估企业在配置与发布管理方面做得到底怎么样?还需要在哪些地方进行改进或提高?

两年前,CITCON的几个参与者给出了一个持续集成成熟度模型,聚焦于“持续集成实践”,而在《持续交付》一书中,Jez与Farley也结合ThoughtWorks在这方面的实践经验,总结了“配置与发布管理成熟度模型”,并在多个项目中进行了实际应用,效果不错。

由于这是通用模型,所以各等级中多为定性描述,在拿到具体企业使用时,可以根据实际情况,对其中一些定性描述进行量化,比如“提交不频繁”“定期沟通”等。

如何使用这个成熟度模型呢?

  1. 找出你所在团队在各维度上所处的级别。
  2. 找出你所在团队需要改进的维度,以及在该维度上的改进目标。
  3. 根据目标与现状,制定改进行动计划并实施。
  4. 重新评估,再制定下一个目标。

任何流程都是可以改进的,所以没有最好,只有更好。所以最高一级是“持续优化”。

模型内容可从以下地址下载:

http://download.csdn.net/source/3454593