第6章 走进持续集成的世界
在我们的测试团队转型的过程中，测试环境的基础环境也从虚拟机过渡到了容器环境。因为现阶段我们团队的测试环境的部署和管理已经完全的通过自研的自动部署及持续集成系统接管了，因此说到测试环境的治理，我想先介绍一下持续集成。
6.1持续集成
Grady Booch于1994年出版的《面向对象分析设计与应用》（Object-Oriented Analysis and Design with Applications）第二版中首次提出了持续集成（Continuous Integration）这种软件开发流程，这种流程要求所有工程师将各自的代码开发的副本每天集成到主线上。持续集成的概念之后被极限编程引入，来解决极限编程中被称为"集成地狱"的问题。在软件开发的流程中，系统集成经常是一件让人提心吊胆的事情，为了使这一过程风险最小化，极限编程中提倡在开发过程中每天进行一次至数次集成，使集成风险分散，将问题解决在萌芽状态。
6.1.1实践
在很多团队中，未必能始终贯彻极限编程，但是持续集成却已经被广泛的投入使用。比较典型的持续集成过程如图6-1所示：
图6-1 持续集成过程
在实践的过程中，你需要关心更多的细节：
1.首先需要使用版本控制系统来维护代码库，比如现在被广泛实用的Git，和其他诸如SVN，CVS，Jazz等等。所有与系统相关的应用都在这个代码库中维护。代码库中的模块要有合适的边界，以及结构。如果模块有多层嵌套定义的话（比如模块中还定义了模块）有可能为我们扩充流水线的功能带来麻烦，比如收集代码覆盖率时，现有工具对这种结构的工程支持并不是很完善，导致覆盖率收集失败（我们在想通过sonar扫描代码并收集单元测试覆盖率时遇到了这样的问题，并且最终没有得到妥善解决，但其实经过合理的设计，一般情况下是可以避免这种工程结构的）。
2. 必须拥有自动化的构建能力。以前有MAKE，Ant等工具，现在在Java的世界里有Maven和Gradle。这两种工具不光可以用来处理应用包的依赖问题，配合不同的插件（也同样是软件包），同样可以方便的打包，甚至运行单元测试，这极大地简化了流水线的相关功能的开发工作。
3. 每人每天至少进行一次代码的提交，通过相对频繁的提交代码来减少冲突的量以及解决的难度。如果相隔较长时间才进行将大大地提高集成时的风险，有时甚至需要花费比开发代码还长的时间来解决冲突。在代码提交和流水线构建中间，最好不要有窗口时间，这样可以避免其他的提交影响构建或测试的结果，有助于问题的定位。即使有测试失败，或者构建失败，也可以明确的知道是那一次提交引起的。
4. 仅仅对软件或应用进行构建，那么这个持续集成就是不完整的。持续集成需要配合单元测试（这牵扯到了测试驱动开发的开发形式，我们不做展开讨论了），甚至其他形式的自动化测试，来对最新的代码进行测试，以保证新代码的质量的底线。为什么说保持底线，而不要求在流水线里对代码进行充分测试呢？因为持续集成要求构建结果得到快速、有效地反馈。这就要求我们精心的设计和挑选在流水线中运行的测试用例集了，一般除单元测试以外的其他测试，比如接口测试，UI自动化测试等等，我们或挑选出一个较小的BVT测试用例集来在流水线上运行。其他的用例留待测试环境中通过其方式运行。
5. 不论是什么样的持续集成，最后都应该有一个产出物。可以是jar/war包，Android/iOS应用的安装包，甚至是一些静态资源，一个文本文件等等。这些产出物，以及他们的相关信息，比如代码版本、构建时间、相关测试结果等等。都应该被妥善地保存，并且所有人都可以方便地检索，获取相关信息和构建历史。这样将有助于问题的排查和历史回溯。
6.自动部署，大部分的持续集成系统都支持在构建后直接将最新版的应用部署在测试环境中，尤其是如果接口测试或者自动化的功能测试作为流水线的一环的时候，自动部署就是一个必须满足的条件了。在很多先进的系统中，在自动部署到了测试环境，并运行了相应的测试后，可以将测试通过的版本直接部署到预发，甚至生产环境中。进而，实现了持续交付（Continuous Delivery）。
6.1.2持续集成的投入和回报
做持续集成需要投入什么呢？
首先，构建一个持续集成系统需要投入大量的时间和精力，之后同样需要持续的投入资源去维护和扩展新功能以适应项目的迭代发展；其次，围绕持续集成展开的测试自动化工作同样需要大量的投入，开发者和团队管理者需要仔细权衡在每一种自动化测试形式上所投入的资源，以决定每种自动化测试做到何种程度，同时这些自动化测试同样也需要不断维护以覆盖新功能或者适应产品的更改；再次，持续集成需要比较富裕的硬件资源来支撑多个产品的持续集成过程，如果运行环境不足的话，开发人员的集成请求可能会排很长时间的队，导致无法及时得到上次代码集成的结果，会极大地影响他们的工作效率，同时这样的一个基础硬件环境同样需要专业的团队进行维护，又是一笔不小的投入。
做持续集成成本高周期长，那么它能否给我们带来可观的收益呢？我认为总的来说还是值得的。首先，持续集成可以帮助我们尽早的发现错误，从软件的缺陷修复成本来看，越早发现的缺陷，解决起来成本越低；因为频繁的集成，如果发生错误，开发人员只需要放弃小部分修改就可以使整个系统恢复正常，有助于线上问题的快速排除。其次，将自动化测试纪律化、强制化，充分的利用自动化测试，当执行频率提高了，花费在自动化测试开发的时间和人力成本也就能更快的赚回来；再次，任何更改都可以及时的在系统上反映出来，同时也迫使开发做更充分的单元测试，为了应对频繁的提交和构建，开发人员将会提交结构更合理，质量更高的代码，使得产品维护成本降低。
相关推荐：
版权声明：51Testing软件测试网获人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
