持续集成(Continuous Integration)基本概念与实践

本文由Markdown语法编辑器编辑完成。

From https://blog.csdn.net/inter_peng/article/details/53131831

1. 持续集成的概念

持续集成(Continuous Integration)的概念有很多不同的版本,持续集成的出现是为了配合敏捷开发(相对于瀑布开发)的速度和效率而产生的一个用于编译、测试、发布、部署的工具。

为什么叫持续呢?因为编码人员每天都会向项目提交代码,因此项目源码每天都会发生改变,为了能够验证最新的代码是否能够被成功编译,是否会影响前面迭代已经通过的自动化测试case,是否能够打出完整的可执行包供测试人员进行测试……。通过每天,甚至是每次提交代码后的持续集成,可以很快地得到反馈,并且易于追溯,即使出了问题也很容易知道是由于哪一位开发人员的提交而导致的。

持续集成(CI)是一种实践,可以让团队在持续的基础上收到反馈并进行改进,不必等到开发周期后期才寻找和修复缺陷。

通俗一点儿说:
就是指对于开发人员的每一次代码提交,都自动地把Repository中所有代码Check out到一个空目录,并且自动运行所有Test Case。如果成功则接受这次提交,否则告诉所有人,这是一个失败的Revision。

持续集成一般通过编写好的python等脚本,自动完成一系列集成所需要的步骤。从代码的check out, 构建项目工程,编译源代码,生成可执行包或安装文件,压缩打包,上传到公司或项目组的FTP等位置……

如果不想每次提交都去集成的话,可以选择在一个固定的时间点去集成,比如每天晚上等项目组的所有成员都已经把当天的代码提交完毕后,启动集成。当第二天上班的时候,测试人员会去FTP下载最新的项目包,开始测试开发人员前一天提交的代码是否正确。这也是Daily Build的概念来源,即每日构建。

2. 持续集成的工具

有一篇文章介绍了持续集成的八大工具,分别是:

  • Hudson
  • CruiseControl
  • Continuum
  • QuickBuild
  • Bamboo
  • Jenkins
  • TeamCity
  • CI-Eye

关于这几个持续集成工具的详细介绍,可以参考这篇文章:
《八大持续集成工具》http://openskill.cn/article/218

我在三年半的工作生涯中,接触过的两个持续集成工具分别是Bamboo和Jenkins,因此对这两个持续集成工具比较亲切,但是真正了解得很少。一时,这个工具一般都是自动运行,很少需要人的参与,除非前一天构建失败后,需要登录工具去下载失败的log;二来,这个也主要是项目经理和测试组会经常访问的工具,开发人员一般只负责提交代码到SVN即可。

但是,不管是哪一个持续集成工具,它本质上只不过是一个定时器,时间一到,做你脚本里让它去做的事。如果,想要扩展持续集成的作用,则需要将这个工具与其他的工具结合,才能显示出持续集成的本色。

比如,如果想增加测试工具,选择JUnit, JWebUnit, Selenium等;
想检查代码标准,需要用checkstyle, sonarqube等代码规范检查工具;
想了解测试覆盖率,可以用Istanbul, JCoverage等工具;
想打包生成二进制文件,要用Ant, Make之类的工具。

参考链接:

  1. 持续集成(CI)、自动化构建和自动化测试—初探
    http://www.cnblogs.com/chaoa/articles/4447354.html
  2. 八大持续集成工具
    http://openskill.cn/article/218
  3. Bamboo的地址
    https://www.atlassian.com/software/bamboo
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/inter_peng/article/details/53131831
上一篇:【转】谈谈Google Polymer以及Web UI框架的未来


下一篇:UI学习之常用方法(续)