浅谈持续集成

最近在看软件质量保障相关的一些资料，持续集成占据了其中很大一部分篇幅。这篇文章，主要内容是对持续集成相关知识的整理归纳，以及个人对持续集成的一些思索总结，介绍持续集成的起源、发展以及如何实践。

相关阅读推荐：

《持续集成：软件质量改建和风险降低之道》

《持续交付：发布可靠软件的系统方法》

一、起源与发展

1、起源

持续集成这个术语最早是在1994年由Grady Booch提出的，目前能看到的关于持续集成最多的描述，来源于Martin Flower发表的一系列论文。Martin Flower也对微服务架构的流行贡献了最大的力量，主要源于其2014年发表的论文《Microservice》。关于微服务架构，我之前整理了一篇文章，感兴趣的可以去看看，传送门：https://www.cnblogs.com/imyalost/p/6792724.html

Martin Flower为持续集成总结了以下一些原则：

①、维护一个统一的代码库；

②、每天都必须向主干提交代码；

③、每次提交都应立刻在集成环境进行构建；

④、自动化构建；

⑤、自动化测试；

⑥、自动化部署；

⑦、快速、持续构建；

⑧、构建环境务必于生产环境保持一致；

⑨、访问权限对团队成员保持公开透明；

2、定义

持续集成-CI（Continuous Integration）：对软件项目进行持续的自动化的编译打包构建测试发布，来检查软件交付质量的一种行为。

3、组成

自动编译+自动代码检查+自动打包+自动化测试+自动部署

4、演进

模式：互联网机会窗口期的不断缩短，需要快速交付，快速发现问题解决问题

角色：功能测试→自动化测试、性能测试、安全测试→测试开发（对软件研发过程提供各种支持，包括工具，框架，方案，最佳实践）

岗位：开发、测试的岗位界限越来越模糊，由原来的DEV、TEST向质量保障靠拢（可参考《Google的软件测试之道》，这本书介绍了Google是如何做测试的）

5、工具

AnthillPro：商业的构建管理服务器，提供C功能

Bamboo：商业的CI服务器，对于开源项目免费

Build Forge：多功能商业构建管理工具，特点：高性能、分布式构建

Cruise Control：基于java实现的持续集成构建工具

CruiseControl.NET：基于C#实现的持续集成构建工具

Jenkins：基于java实现的开源持续集成构建工具，现在最流行和知名度最广泛的持续集成工具

Lunt build：开源的自动化构建工具

Para Build：商业的自动化软件构建管理服务器

二、为什么要做持续集成

1、项目中常见的问题

①、集成时发现系统无法运行；

②、不同分之之间合并代码经常出错；

③、加班加点改BUG；

④、重复进行手工的部署、调试、测试、发布，成本高，风险大；

⑤、其他。。。。。。

2、团队文化问题

①、对交付软件的质量意识不足

②、无法做到优先处理失败的构建

③、工程师文化不足

④、团队管理、流程的不足

3、持续集成的优点

持续集成能提升交付效率和交付软件的质量

①、及时反馈结果，尽早发现问题；

②、自动化代替手工，工程师将更多的时间精力放在设计、需求分析、风险预防等方面；

③、持续集成→持续交付→DevOps→基于容器的服务→提高自动化程度来提高效率；

三、从零开始构建持续集成

CI = 高效的构建+全面有效的测试+合理的流程规范+工程师文化+ROI

1、高效的构建

①、高效的构建：主干开发是快速推进CI的有力基础

核心：源代码、测试用例、配置和数据统一管理

优势：解决merge回主干困难，回归成本高的问题

解决随着项目增多，分支增多，管理越来越难的问题

修复BUG，可以达到修改主干，多出都可以fix的效果

解决QA只保证单独分支质量，忽视merge后主干质量的问题

②、高效的构建：需要工具支撑

版本控制：git&SVN

代码管理：gitlab私有部署

基础环境：虚拟机、docker、kubernetes

自动构建：jenkins

反馈机制：邮件&短信&微信&钉钉

具象方式：打造符合团队需要的pipeline

2、全面有效的测试：测试存在于项目周期各个阶段

①、需求与设计：PM/DEV/QA

需求评审

需求变更

设计评审

②、开发与测试：DEV/QA/PM

code review、单元测试

测试方案、测试用例、BUG管理、风险评估

功能测试：冒烟、集成、系统、验收

性能测试、安全测试、容灾测试

线上验证、探索性测试

③、上线与线上：OP/QA/DEV/PM

线上验证

业务监控

用户反馈

产品评测

PS：缺陷发现越早，修复成本越低，反之则越高

3、合理的流程规范

①、代码提交规范

本地开发

本地编译（自测，check out）

提交至当前主干（change log简洁明确）

主干编译（测试，check out）

②、注意事项

提交至主干前做好本地编译、自测

提交前解决代码冲突

提交时及时关联和添加描述

提交后关注代码扫码结果

提交后关注主干集成构建结果

构建没问题后及时合并

③、遵循原则

主干构建失败停止提交代码，直至构建成功

优先修复失败的构建，修复问题

如果构建不能快速修复，执行回滚

4、工程师文化

①、提高对交付软件质量保障的意识（测试是核心）

②、树立优先处理失败的构建的意识（优先程度最高）

③、培养团队工程师文化（流程、质量、沟通、职业素养）

④、优化团队管理、流程各方面，做到精简，避免过分强调流程、避免面子工程、做好资源协调

5、ROI（投资回报率）

①、从0到1，可接受的投入的资源成本

入门阶段可以考虑持续编译打包，及时反馈代码版本库的编译问题冲突问题（快速正向的反馈）；

②、从1到2，选择对整体交付质量，速率提升最高的选项

可以选择性价比较高的持续部署和代码检查，定时code review，减少手工部署和代码级别的BUG造成的风险；

③、从2到3，面临的问题越来越多

挑战：

构建任务的不断增加，执行速度的下降，整体效率的降低，成功率低于期望值；

自动化测试脚本维护量大，依赖于基础测试环境和测试数据的稳定性；

解决方案：

增加任务构建执行机，减少排队现象（多任务分布式构建）；

拆分耗时较长的任务，减少单个任务执行时间，解耦；

将自动化测试放在稍后的阶段实施，分层设计，轻量的UI和重点API层automation，是目前业内较好的自动化测试实践结果；

④、从3到N，不断扩展带来的挑战和期望收益提升

不同团队项目类型、技术栈构成、关注点、工作习惯不同，要求CI具备高度灵活性和定制化；

需要持续不断的资源投入；

团队自发适应、不断调整和优化方案以及流程；

以上内容就是我对持续集成相关资料的整理以及个人的一些思考总结，还存在很多不完善或者不对的地方，如有更好的建议，希望看到的各位不吝指教。。。