CI(Continuous Integration)具体实施方式依赖于项目的开发流程,而CI以自身的一些特点(如,自动化,快速,周期性,定时性等)在敏捷的开发流程(如scrum)中似乎更能体现其价值。本文便是建立在这样的一个项目基础之上的。
项目背景:
- 敏捷的开发流程,3到4周为一个sprint,正常的提交是以sprint为周期的,不排除因其它原因而要求3天内提交。
- 项目多分支——mainline,sandbox,release x...
- mainline为每个sprint的提交分支
- sandbox为开发分支,是开发人员的workspace,会不定时将代码同步至mainline分支
- release为发布分支,是项目发布包到产品测试环境源代码分支。在此分支上只允许bug的修复,并要求同步至mainline分支
- 开发团队多小组(如功能A组,功能B组),每一个小组可以有自己的sandbox分支。
- 开发语言为Java,因此在编译时并没有去考虑编译的性能,直接是全编译。(注:有项目可以考虑使用增量编译的方式)
在这样的项目背景下,针对mainline和release分支都创建了自动化的Job,每个Job的过程大概可以分为以下几个步骤:
- 源代码同步
- 编译
- 单元测试
- 打包部署至测试环境
- 集成测试
- 发布包
流程中会收集每个环节的报告:
- unittest report
- code coverage
- function test report
这些报告将发布到web服务器上,并以邮件的形式将报告的URL通知给相关人员。
此外若最后编译的包也发布成功,那么邮件体中也会包含如下内容:
- 当前版本与上个版本相比的changlist
- 新包的版本号
- 包的发布地址
这样方便测试人员进行后续的人工验证。