持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽快地发现集成错误。
下面来讲讲我的持续集成实施方案：
1、持续集成实施
1.1、持续集成总体流程
持续集成整体流程图
持续集成总体流程说明：
1）开发人员从SVN服务器拉工单或项目分支代码到本地，然后在本地新增功能或修改bug；
2）本地运行单元测试通过后，提交代码到SVN服务器；
3）触发自动编译，编译成功后自动执行动态单元测试；
4）动态单元测试通过，执行静态代码检查及安全扫描；
5）静态代码检查及安全扫描通过，将代码发布到发布服务器；
6）获取更新通知，调用自动化部署平台将版本发布到持续集成环境；
7）发布成功，执行集成测试和性能测试；
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环境、灰度环境和生产环境等。测试失败则终止流程，生成失败报告。
admin
