另一个关于持续集成和版本分支的故事

经典书籍《持续交付》[1]的作者曾就分支合并和代码演化等问题详细地讨论 过滥用分支对持续集成的负面影响。而我今天要说的是这样一个故事，一个只能 申请到非常有限的硬件设备的团队，他们是如何在多分支策略下实践持续集成的 。

一个团队接手了一个项目，需要在开发新特性的同时维护几个发布分支。团队 计划实践持续集成，但手头的硬件资源严重不足，无法满足所有分支的部署流水 线同时运转。

流水线分为三个阶段，分别是：

commit 编译、单元测试和部分集成测试并打包

at 部署应用程序并运行自动化验收测试

uat 部署应用程序并由测试工程师执行手工验收测试

这里我们略去了性能测试阶段和发布阶段，它们一般需要额外安排硬件设备， 与这个故事关系不大。流水线的每一个阶段都可能依赖于某些外部服务，比如Web 容器、数据库等。为防止不必要的干扰，每个阶段通常会尽可能地使用专用的外 部服务，测试工程师在uat阶段做手工测试时可不喜欢Web容器由于at阶段被触发 而被重启。

长生命周期的分支同主干一样也需要部署流水线，也就需要更多的外部服务。 如果主干的at阶段依赖于数据库，那么某个发布分支的at阶段也同样需要依赖于 数据库。而通常你得为它们准备不同的数据库实例以防互相干扰。外部服务的安 装和运行是需要硬件资源的，在资源拮据时，分支无疑加剧了这个问题。由于一 些特殊情况，在好几个项目中我们只申请到了一台破旧的PC server作为团队的测 试设备。但我们并不打算因此放弃持续集成，所以让我们看看能不能在螺蛳壳里 做道场吧。