持续集成是一种沟通方式－－《持续集成》读书笔记
最近看了《持续集成－－软件质量改进和风险降低之道》和马丁福勒的博客，看书的时候感受不是很深，甚至我觉得我都写不出这篇读书笔记。我入职时间不长，进入的项目就在实行CI，很多的CI实践虽然一知半解，但是由于一直在用，所以书中很多的内容对我来说并不陌生。后来我又去读了马丁福勒的博客，有了一些独特的感受，其中最赞同也感触最深的话，我用在了标题里，持续集成的主要工作是沟通。作为一种沟通方式，持续集成可以帮助开发人员快速的交流开发内容，及时的发现并且定位问题。
什么是持续集成
持续集成是指频繁的、经常性的进行代码的集成构建，当代码发生变更时，无论变更的大小，都要执行一次构建，进行单元测试，并且与数据库等进行一次集成。从我所在的项目来说，我们有4个环境，CI环境，QA环境，staging环境，还有生产环境。
QA环境主要用于测试，staging环境可以理解为一个beta版的生产环境，这些环境在这篇文章里都不想过多介绍，主要想要介绍CI环境。
关于CI环境，我的理解就是这是一个最低门槛。所有最新提交的代码都会最先流入这个环境，这个环境会执行一次build，跑一遍单元测试，执行一遍代码审查，查看代码是否可以构建，测试是否都通过，测试覆盖率是否达标，是否有过多的code smell。所以这个环境也是pipeline挂掉次数最多的环境，所有通过这道门槛的代码，都是没有集成问题的代码，可以直接作为产品进行测试。
持续集成中有一个很重要的点就是要使用专门的集成构建计算机，这也是我在看前几页就带着的一个疑问，直到最后才得到了解答。这个专门的集成构建计算机就是我们项目中的CI环境。这个机器就是为项目创造一个共享的干净的集成环境。每一个开发者所使用的机器都会有所不同，有硬件和软件的各种差异，生产环境的各种配置也会与开发者的本地环境有一定差异，我们总要保证提交的代码是可以在生产环境上工作的，或者是可以在任何一台机器上工作的。这台机器就是去排除掉开发者本地环境的种种差异，保证不同的开发者提交的代码可以共同工作。
那么为什么CI不能和QA环境合并呢？如果二者合并，QA的测试过程可能会被打断，因为整个环境在构建，整个程序都被停止，为了保证QA可以正常的工作，需要拆出一台机器或者虚拟机来进行CI的工作。
持续集成的意义
持续集成的好处在于：减少风险、减少重复过程、随时生成可部署的软件、给予团队构建反馈、增强对产品的信心。这几点好处相信所有提CI的文章都会提到，不过多赘述。
说一下个人的理解，持续集成的意义就是沟通。刚才提到的几点好处，我在书中读到过很多次，然而马丁的这个解释，诠释了所有这些好处和CI的意义。为什么说持续集成会降低风险减少重复呢？当多个人在同时开发的时候，可能在同一份文件进行更改，可能做了同样的操作。当需要对多个人做的这些东西进行合并的时候，如何取舍，怎样合并一定是一件极端痛苦的事情，所以好多人称之为“地狱”。
我记得我之前做过一个故事卡，我和另外一组pair的小伙伴做了类似的功能，只是一个很小的功能，合并的过程痛苦不堪，因为我对他们的实现并不了解，解决方案的取舍也是一件艰难的事情，最最痛苦的事情在于花费了时间之后一遍一遍的编译失败。
我之所以非常赞同CI的意义就是沟通就在于，当我完成一点代码，我pull一下代码库，跑一下测试，很快就可以知道我的代码是否与他人有重复，是否可以成功构建。CI实践让我不需要随时跟我的小伙伴进行沟通，就可以快速的知道他们做了什么，我们的代码是否有冲突、是否有重复，而不是在最后合并的时候，几个人坐在一起聊自己的代码，然后痛苦不堪的合并。
通过CI实践，最后合并的时间几乎等于没有，所有提交到CI环境上的代码都是可集成的代码，即可部署的软件，可以帮助团队快速的部署。就我目前的项目来说，我们几乎没有经历过大规模的merge代码，经过CI环境之后，QA可以快速的部署到测试环境，测试通过后就可以快速的上线。
CI还有一个很重要的实践就是反馈。这一点我感受最深的就是在TWU的时候，我们团队有一个显示屏，专门用来显示CI的状态，当CI挂了的时候，其他人就不会去pull或者push代码，最后提交代码的人也会快速去修复。这样就不会有人因为别人的代码而反复的定位问题，也不会有多个人同时工作在寻找为何无法成功构建上而导致做了过多重复的工作。
CI的实践就是一种高效的沟通，不需要言语的表达，也不需要打断每个人的工作节奏，团队的成员就会了解到其他人的工作，知道自己接下来应该如何去做。
持续集成与敏捷实践
持续集成是敏捷实践的一环，为敏捷实践中向客户持续进行交付打下了一定的基础。在项目中，持续集成的使用很大程度上也反映了团队的敏捷程度。这一阵子我们团队进行了敏捷成熟度的评估与改进，有一部分与持续集成密切相关的：
- 开发演示：开发人员是否在充分完成自测后，在部署的开发或测试环境下给测试人员进行当面演示，在主流程和基本场景都通过的前提下测试人员再做完整故事测试
- 代码评审：团队是否建立了每天例行的代码评审机制，对每天提交代码的质量进行集体评审，并有机制确保评审发现的问题都进行了修复
- 代码静态分析：团队是否利用了工具频繁（比如每日代码提交，或每日多次）对提交的代码质量进行静态分析，并且团队能立即对发现的不良问题（严重级别以上的问题，高重复率，高复杂度）进行修改，不遗留问题
- 单元测试：开发人员是否为新增和修改的代码创建了单元测试来验证其正确性，并且这些单元测试能够通过持续集成来频繁地执行，保证持续有效
- 自动化功能测试：团队是否创建了有效的自动化测试脚本来对组件或系统的功能进行测试（包括服务接口测试和UI测试），并且这些测试脚本能够通过持续集成来频繁地执行，保证持续有效；而且团队遵循“测试金字塔”原则，不同层级的测试有合适的覆盖范围
- 自动化非功能管理：团队是否利用工具模拟对系统或应用的性能，安全性，并发稳定性等非功能性质量进行了验证，并且这类验证也是尽可能自动化的，可频繁执行
- 统一配置管理：团队是否采用了统一配置管理，即包括应用代码、单元测试、自动化测试脚本、自动构建脚本、数据库变更脚本、环境配置等以合理的目录结构存放在统一的源代码库中，全部进行版本化管理
- 单主干开发：开发团队是否采用了“单主干+发布分支”的分支策略：每天新的代码频繁提交到唯一主干，没有特性分支；在迭代结束时创建或合并到发布分支来为发布提供稳定版本；甚至能直接从主干发布
- 持续集成：团队是否建立了有效的持续集成流水线，频繁地自动化地对代码进行构建，快速获得反馈；该构建过程应包括编译、静态分析、执行各类测试、产生包、各环境自动部署等；构建成功或失败能立即通知到团队，一旦失败团队能够立即关注并解决导致错误的问题（或回滚代码）让构建通过
- 分层构建：针对同一个代码库，团队是否为不同的目的建立了不同层级的持续集成流水线以合理的不同频率执行不同的任务组合，从而平衡执行频率和执行效率的矛盾，更快获得构建反馈
- 环境管理：团队是否为开发验证、集成测试、自动化测试、以及预生产发布等各准备了独立的环境来支持各级验证环节，且每个环境有明确的目的并随时稳定可用；最好是这些环境能够以脚本来定义和自动化变更其配置
其中，开发演示、代码评审、代码静态分析、单元测试、自动化功能管理和自动化菲功能管理属于评估中质量保证的内容，质量保证的评估总共8项，一半以上都与持续集成有关。其他五项属于敏捷成熟度评估的持续交付的内容，持续交付中共有7项评估内容，也是一半与持续集成有关。持续集成是敏捷实践中很重要的一项内容，我的理解是，持续集成对于让团队变的敏捷是一个必要条件。
