持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误。
下面来讲讲我的持续集成实施方案。
1持续集成实施
1.1持续集成总体流程
持续集成整体流程图
持续集成总体流程说明:
1)开发人员从SVN服务器拉工单或项目分支代码到本地,然后在本地新增功能或修改bug;
2)本地运行单元测试通过后,提交代码到SVN服务器;
3)触发自动编译,编译成功后自动执行动态单元测试;
4)动态单元测试通过,执行静态代码检查及安全扫描;
5)静态代码检查及安全扫描通过,将代码发布到发布服务器;
6)获取更新通知,调用自动化部署平台将版本发布到持续集成环境;
8)集成测试和性能测试通过,视情况将版本发布到集成测试环境、UAT环境、灰度环境或生产环境。
9)在持续构建的整过程中,能实时查看构建进度、构建状态、构建结果等详细信息。
1.2持续集成流程分解:
持续集成流程分解图
1.2持续集成详细策略
1.2.1持续集成之配置管理
1、代码和构建产物的配置管理:
全面的配置管理,项目的配置文件、构建脚本、数据库脚本、部署脚本,依赖库内容全部纳入版本管理。制定有效的分支策略。目前,使用分支开发、分支发布的开发模式进行持续集成工作,目的是先丰富项目单元测试和验收测试用例。后期逐步转换到基于主干的开发模式。
构建产物,构建的二进制文件不推荐放到版本库中。二进制部署包只构建一次,避免多次构建可能产生的差异。
2、环境管理
部署环境标准化。开发、测试环境要向生产环境靠拢,尽量做到类生产环境的配置,包括补丁版本,依赖软件版本,中间件版本。同时,我们可以考虑使用容器化部署方式统一开发、测试、生产环境。
3、应用的配置管理
使用应用二进制包和配置文件分离的方式,抽离应用与环境相关的配置文件,保证二进制包代码的一致性。后期,使用统一的配置中心(CMDB)管理维护应用的所有配置信息。
1.2.2持续集成之持续构建
持续构建阶段依赖持续集成工具jenkins,分两阶段自动完成构建。第一阶段构建完成代码的编译及动态单元测试,第二阶段构建完成静态代码检查、安全测试,并发布到持续集成环境,然后执行完集成测试、性能测试等,在构建的过程中能实时查看构建进度、构建结果及测试报告等。在构建异常时,需要开发人员快速响应,及时解决,然后重新构建。如下图所示:
持续构建图
持续构建流程说明:
1)开发人员从主干拉工单或项目分支;
2)每位开发人员在开发新代码之前,只能从持续集成完全成功的新拉的分支检出最新代码;
3)开发新功能或修改bug;
4)运行本地测试,如果有失败就立即修复,直到测试成功;
5)提交前将分支最新代码取到本地合并;
6)运行本地测试,确保测试通过;
7)获取提交令牌;
8)提交代码到分支,由持续集成服务器再次运行测试。此时只运行动态单元测试。
9)如果执行成功,执行第二阶段的构建,执行第10步操作;如果执行失败,由代码提交人员查找失败原因,从第2步开始重新执行构建;
10)每晚定时进行第二阶段的持续集成,调用自动化部署平台将代码发布到持续集成环境,然后运行静态代码检查、集成测试、安全测试及性能测试用例;
11)第二阶段持续集成成功后,可将分支代码发布到集成测试环境、UAT环境、灰度环境或生产环境。
12)在整个自动构建过程中,构建出现异常,测试出现失败
1.2.3持续集成之自动化测试
自动化测试按照用例运行快慢、对外部环境的依赖程度及业务验证范围等维度,将自动化用例分成多层,在自动构建的不同阶段分别执行不同层的自动化用例,以保障构建的准确性及构建效率。自动化分层如下图所示:
分层自动化
自动化分层说明:
1)第一层:单元测试、安全测试。用例运行快,易维护,不依赖外部环境。
2)第二层:集成测试、性能测试。用例运行较慢,依赖外部环境。
3)第三层:验收测试。全业务线功能验收,用例运行时间长,依赖外部环境。
1.2.4持续集成之自动发布
自动发布即持续集成工具Jenkins调用自动化部署工具,将分支代码自动发布到持续集成环境、集成测试环境、UAT环境、灰度环境和生产环境。在自动发布的过程中,应用依据具体的实际环境,动态生成应用配置,自动启动应用,持续探测应用的存活,并实时生成发布报告。自动化发布流程如下图所示:
自动发布图
自动发布说明:
1)采用定时发布或手动触发的方式,调用自动化部署平台,执行发布;
2)发布成功则执行集成\性能测试,发布失败则终止流程,生成失败报告;
3)集成\性能测试通过,则可调用自动化部署平台,视具体情况,将基线版本发布到集成环境、UAT环境、灰度环境和生产环境等。测试失败则终止流程,生成失败报告。