《持续交付》笔记——第3章 持续集成

作者：蓝白云

书中提到的问题我们正好也遇到过。在我们团队2009年实施敏捷的时候就开始执行了持续集成实践，一直到现在还在继续。巧的是，有些解决办法也有些相同。例如：首先得在本地构建成功，然后再提交到持续集成集成环境中（准确地讲是提交到SVN版本控制库或Git分布式版本控制库中，持续集成自动会从版本控制库中获取代码构建编译和测试）。

持续集成的核心在于自动化测试，验证提交的代码是否符合功能需求或非功能需求，除了它，那与普通的自动化编译没什么区别了。

持续集成并不是一种工具，而是一种实践。它创建了一个快速的反馈机制（包括但不限于：自动编译、自动化单元测试、自动化验收测试、自动化性能测试、代码静态检查、覆盖率统计、生成发布包等等），使项目尽早暴露问题，降低项目成本。

文中提到一些必不可少的实践（自己选取了一些重点）：

• 一旦持续集成构建失败，项目组应在第一时内响应，并使其恢复到成功状态再继续提交新代码；
• 回家之前，构建必须处于成功状态；
• 不要将失败的测试用例注释掉；
• 做到测试驱动开发；
• 如果违背架构原则，就让构建失败；（估计这个大家基本上不会去做）
  

想像一下，如果没有持续集成，敏捷则无从谈起。