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

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

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

流水线分为三个阶段,分别是:

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

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

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

长生命周期的分支同主干一样也需要部署流水线,也就需要更多的外部服务。如果主干的at阶段依赖于数据库,那么某个发布分支的at阶段也同样需要依赖于数据库。而通常你得为它们准备不同的数据库实例以防互相干扰。外部服务的安装和运行是需要硬件资源的,在资源拮据时,分支无疑加剧了这个问题。

相对其他外部服务,数据库是一个吃硬件资源的大户。

在流水线的某些阶段,可以使用一些替代方案,比如commit阶段,可以把持久化测试运行在embeddedhsqldb上,这样可以去除此阶段对数据库实例的需求,而且这样commit阶段的构建时间应该会有所减少。

后续at和uat的功能验收测试最好运行在与生产环境相同类型的数据库上。

Web中间件是另一个大头,不过这里目前团队也没发现有什么特别的办法。可以考虑在部署脚本中使用参数化的contextPath,这样在同一个Tomcat或是Weblogic中可以部署多个环境的应用程序,但是这样一来加大了配置难度,二来节约的资源有限,所以基本上还是通过一个环境一个Tomcat或是一个Weblogic的一个Domain来实现的。

如果应用程序还依赖消息组件,那么还应该准备流水线各阶段专用的消息中间件。不像数据库,共享消息中间件而引发的问题比较隐蔽。

我们只有一台server模式的ActiveMQ,而手工测试环境和试生产环境都监听其中同一个消息队列,手工测试环境的应用程序消费了试生产环境的应用程序发出的消息。于是我们另外搭建了一台server模式的ActiveMQ,让它们分别监听,问题就解决了。这件事让我意识到,作为一个有状态的组件,消息中间件也是环境敏感的。当然,一个好消息是消息中间件需要的硬件资源一般没有数据库那么多(多安装一个ActiveMQ和多安装一个Oracle实例相比),所以最简单的做法就是再装一个。

事实上,有时不同的开发人员会向配置管理员询问同一个发布分支的broker地址。由于它们不容易与对应的环境联系起来而且多少还是需要占用一些硬件资源的,于是我们决定裁剪ActiveMQ实例。

实践持续交付是一个长期的渐进式的过程,往往会遇到各种个性化的问题。有的组织硬件资源不足,有的组织硬件资源充足,但还不能做到自动化环境管理。于是许多准备尝试部署流水线的团队会在流水线环境准备上遇到困难,希望这个故事能对这样的团队有帮助。有时候,外部环境或自身资源的限制也不完全是件坏事,这使我们停下细细思考,到底流水线的方案还有哪些可以改进的余地,办法总比困难多。

 

 

题图来自网络。

 微信号:IdeaofSE

来源:软件工程之思,本文观点不代表自营销立场,网址:https://www.zyxiao.com/p/95213

发表评论

登录后才能评论
侵权联系 投诉举报
返回顶部