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

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

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

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

这两种变化都是慢慢地增量式地完成的，在改变的同时，也做新功能的开发，但这并不妨碍我们每天向Mercurail的版本库主干上提交数次代码，甚至在切换过程中做了数次正式发布。我们是如何做到的呢？

全文请见《持续交付》中文站。