Continuous Integration实践之Process

 

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的过程大概可以分为以下几个步骤：

1. 源代码同步
2. 编译
3. 单元测试
4. 打包部署至测试环境
5. 集成测试
6. 发布包

 

流程中会收集每个环节的报告：

 

• unittest report
• code coverage
• function test report

这些报告将发布到web服务器上，并以邮件的形式将报告的URL通知给相关人员。

 

此外若最后编译的包也发布成功，那么邮件体中也会包含如下内容：

 

• 当前版本与上个版本相比的changlist
• 新包的版本号
• 包的发布地址

这样方便测试人员进行后续的人工验证。