“持续集成”也需要重构(下)

发表于:2009-7-02 14:51

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:乔梁    来源:InfoQ

#
敏捷
分享:

 过程化持续集成 —— 消除浪费

  实际问题

  开始使用阶段式持续集成时,由于不用改太多的构建脚本,而且也初步达到了目的。可是随着时间的推移,代码越来越多,逻辑越来越复杂,问题定位令我们头痛,而且每个构建计划都要重新编译和打包等重复性工作也让团队不爽。

  理论基础

  过程化则是将每一个步骤单元化,并顺序执行。如第一个单元是CheckStyle,编译及单元测试,第二个单元是打包生成软件,第三个单元是“部署并进行功能测试”,第三个单元是“性能测试”。这种过程化分解因去除了重复步骤,所以更有效率,而且每次执行时,代码可以顺序经历一系列的测试。

图5 过程化构建图解

  该类型集成的关键在于让所有这些分离的单元可以顺序执行。首先,编译过程被调用,一旦编译单元成功结束,下一单元(快速测试)即开始。正是此刻,我们遇到了第一个复杂性。由于第二个单元(如快速测试)并不是一个完整的过程,所以并不能用它自己产生的产物来测试。而这一点恰恰是过程化持续集成的的关键:将构建与测试分离以节省时间,这也是其与阶段性集成的不同之处。由于后续单元并不产生测试所需要的产物,就要从外部获取,而这些产物正好产生于前面的单元。因此,运行前面单元时,它要将这些产物放在一个已知位置,而后续的单元从这个已知位置拿到产物。图5所示,U4成功后,P3从U4处拿到代码进行打包;P3 结束后,F2从P3处拿到交付物进行部署和功能测试,F2成功后,P2再开始运行。

  利弊分析

  优点:消除和重复工作,提供了持续的信息反馈,反映了整个的过程。

  前一个构建计划U2失败后,后续的构建计划P2也不会从U2中拿取产物来运行,而是等待拿U3的结果来运行,从而也有效的利用的资源。

  缺点:团队自己管理的内容多一些,复杂一些。

  由于各个构建计划之间是各自独立的,所以它们之间的依赖关系由它们之间传递的参数表现。当您想追踪某个后续构建计划为什么失败时,你必须找到这个参数。可这种过程化持续集成并没有提供一个内在功能来完成它,所以你必须自己再多做一点儿工作,而且前后构建单元之间的产物传递也要自己来完成。产物传递看上去要复杂一点儿。因为最近一次构建的结果很容易将前一次的结果覆盖掉。解决这一问题的一种方法是将每次构建的结果分开存放,而后续的单元要知道在哪里可以找到它们所需的文件。利用构建编号做为目录名来保存构建结果时,后续的单元就需要知道这个构建编号,以便找到它所需要的文件。尽管这不难做到,但还是需要做一点儿工作才能做到的。

  另外,由于这种方式需要准备产品的中央存储空间,建立命名规则,修改我们的构建代码,以便在各过程之间传参数。另外,这种模式还是不能从根本解决问题定位这个难题。

  团队结论

  由于采用这种方式的管理复杂性较高,在我们的环境中,潜在的时间消耗也不少,所以我们放弃了这种集成方式。

41/41234>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号