《持续交付 发布可靠软件的系统方法》读书笔记
持续集成
持续集成要求每当有人提交代码时，就对整个应用进行构建，并对其执行全面的自动化测试集合。 而且至关重要的是，假如构建或测试过程失败，开发团队就要停下手中的工作，立即修复它。持续集成的目标是让正在开发的软件一直处于可工作状态。高效使用持续集成的那些团队能够比那些没有使用它的团队更快地交付软件，且缺陷更少。在交付过程中，缺陷被发现得越早，修复它的成本就越低，因此也就大大节省了成本和时间。
实现持续集成
- 版本控制 - 与项目相关的所有内容都必须提交到一个版本控制库中，包括产品代码、测试代码、数据库脚本、构建与部署脚本，以及所有用于创建、安装、运行和测试该应用程序的东西。
- 自动化构建 - 你要能在命令行中启动构建过程。
- 团队共识 - 持续集成不是一种工具，而是一种实践。它需要开发团队能够给予一定的投入并遵守一些准则，需要每个人都能以小步增量的方式频繁地将修改后的代码提交到主干上，并一致认同“修复破坏应用程序的任意修改是最高优先级的任务”。如果大家不能接受这样的准则，则根本无法如预期般通过持续集成提高质量。
持续集成的前提条件
- 频繁提交 - 对于持续集成来说，我们最重要的工作就是频繁提交代码到版本控制库。每天至少应该提交几次代码。
- 创建全面的自动化测试套件 - 如果没有一系列全面的自动化测试，那么构建成功只意味着应用程序能够编译并组装在一起，假如能够有一定程度的自动化测试，会让你更有信心说：“我们的应用程序是可以工作的。”
- 保持较短的构建和测试过程 - 理想情况下，提交前的预编译和测试过程，以及持续集成服务器上的编译和测试过程应该都能在几分钟内结束。
- 管理开发工作区 - 对于保证开发人员的开发效率与明晰思路来说，开发环境的管理是特别重要的。
使用持续集成软件
当今市场上有很多产品可以提供针对自动化构建和测试过程的基础设施。持续集成工具最基本的功能就是轮询版本控制系统，查看是否有新的版本提交，如果有的话，则签出最新版本的软件，运行构建脚本来编译应用程序，再运行测试，最后将运行结果告知你。
必不可少的实践
持续集成是一种实践，不是一个工具，它的有效性依赖于团队纪律。要让持续集成系统能够发挥作用，尤其是面对一个大型复杂的持续集成系统时，整个开发团队就必须有高度的纪律性。持续集成系统的目标是，确保软件在任何时候都可以工作。为了做到这一点，下面是我们在自己的团队中使用的一些实践。
- 构建失败之后不要提交新代码；
- 提交前在本地运行所有的提交测试，或者让持续集成服务器完成此事；
- 等提交测试通过后再继续工作；
- 回家之前，构建必须处于成功状态；
- 时刻准备着回滚到前一个版本；
- 在回滚之前要规定一个修复时间；
- 不要将失败的测试注释掉；
- 为自己导致的问题负责；
- 测试驱动的开发；
推荐的实践
- 极限编程开发实践；
- 若违背架构原则，就让构建失败；
- 若测试运行变慢，就让构建失败；
- 若有编译警告或代码风格问题，就让测试失败；
小结
持续集成的使用会为团队带来一种开发模式上的转变。没有持续集成的话，直到验证前，应用程序可能一直都处于无法工作的状态，而有了持续集成之后，应用程序就应该是时刻处于可工作状态的了，虽然这种自信取决于自动化测试覆盖率。持续集成创建了一个快速的反馈环，使你能尽早地发现问题，而发现问题越早，修复成本越低。持续集成需要良好的团队纪律提供支持。事实上，哪种流程不需要纪律呢？其不同之处在于，有了持续集成之后，就有了一个“该纪律是否被严格遵守”的信息指示器：构建应该保持在常绿状态。假如发现构建是绿的，而大家却并没有足够地遵守纪律，比如没有达到单元测试覆盖率，你就能非常容易地将各种检查加入到持续集成系统中，强制团队养成良好的行为习惯。
