《Continuous Delivery》的原文摘录
-
我们倾向于将自动化验收测试限于完全覆盖 happy path 的行为，并仅覆盖其他一些极其重要的部分。 一个好的自动化测试套件应该给你足够的信心执行重构，甚至对应用程序架构进行重构。 你需要监控到底花了多长时间做重复性的手工测试，以便决定什么时候把它自动化。一个很好的经验法则就是，一旦对同一个测试重复做过多次手工操作，并且你确信不会花太多时间来维护这个测试时，就把它自动化。 (查看原文) —— 引自章节：业务导向且支持开发过程的测试 -
Done Means Released (查看原文) —— 引自第27页 -
Never Go Home on a Broken Build (查看原文) —— 引自第68页 -
Always Be Prepared to Revert to the Previous Revision (查看原文) —— 引自第69页 -
Failing the Build for Slow Tests (查看原文) —— 引自第73页 -
Don’t Delete the Old Files, Move Them (查看原文) —— 引自第271页 -
将测试、部署和发布活动也纳入到开发过程中，让它们成为开发流程正常的一部分。 确保每个人都成为这个软件交付过程的一份子，无论是构建发布团队、还是开发测试人员，都应该从项目开始就一起共事。 你应该具有重建生产环境的能力，最好是能通过自动化的方式重建生产环境。 (查看原文) —— 引自第7页 -
一个更可控的分支策略（我们强烈推荐的，可以说是业界标准）是：只为发布创建长周期的分支。 (查看原文) —— 引自第318页 -
流模式开发的问题之一就是晋升是在源代码级别完成的，而不是二进制级别。因此，每次将一个修改晋升到更高层级的流上时，都必须签出代码并重新构建二进制包。它破坏了我们建议的一个关键实践：发布时所用的二进制就应该是那个已经顺利通过部署流水线的原始二进制包，这样才能确保发布的东西就是测试过的东西。 (查看原文) —— 引自第327页 -
如何管理一个有很多开发人员，且有多个版本发布的大型团队呢？这个问题的答案是：软件需要良好的组件化、增量式开发和特性隐藏（feature hiding）。 (查看原文) —— 引自第329页 -
我们这里的建议并不是一个技术上的解决方案，而是一种实践：一直向主干提交代码，并且至少每天一次。假如你认为，对代码做重大修改时不适合这么做的话，那我们有理由认为，你也许根本没有努力尝试过。 根据我们的经验，虽然使用一系列小的增量步骤来实现某个功能，又要保持软件一直处于可用状态的这种做法有时需要花更长的时间，但其收益也是巨大的。 让代码一直处于可工作状态是非常基本的要求，要想持续交付有价值、可工作的软件，怎么强调这个实践都不过分。 (查看原文) —— 引自第330页 -
当使用“按发布创建分支”的方式时，有一点非常重要，那就是不要在已有的发布分支上再创建更多的分支。所有的后续分支都应该是从主干上创建的，而不是已有分支上。从已有分支上创建分支是一种“梯型”结构，这样很难发现两个版本之间哪些代码是公共的。 (查看原文) —— 引自第333页 -
请将配置信息放在版本控制系统中。这个最简单的动作就是一个巨大的进步。 (查看原文) —— 引自第15页 -
开发人员对代码库的每次修改都应该是以某种方式为系统增加价值。每次代码到版本控制系统的提交都应该是对当前所开发软件的提高或增强。 我们如何知道它的正确性呢？唯一的方法就是运行这个软件，看它的行为是否符合我们的期望。大多数项目都将这部分工作推迟到了开发的后期。这就意味着，即使它不能工作，也只有当有人测试或使用这个软件时才能发现，而此时的修复成本通常会比较高。 这个阶段通常称作集成阶段，常常是整个开发过程中最不可预测、最不易管理的阶段。由于集成这件事太痛苦了，所以团队总是推迟集成工作。然而，集成频率越低，集成时我们就会越痛苦。 如果在软件开发中的某个任务令你非常痛苦，那么解决痛苦的方法只有更频繁地去做，而不是回避。 (查看原文) —— 引自第18页 -
持续集成系统的职责就是推翻这一假设，证明某个版本呢并不适合部署到生产环境中。 (查看原文) —— 引自第19页 -
提前并频繁地做让你感到痛苦的事。 (查看原文) —— 引自第20页 -
提交阶段的目标是在那些有问题的构建引起麻烦之前，就把它们拒之门外。 (查看原文) —— 引自第138页 -
记住，计算能力是廉价的，而人力是昂贵的。及时得到反馈比准备几台服务器的成本要有价值得多。 (查看原文) —— 引自第151页 -
(1)提交频率变低；(2)如果提交阶段的用时远远超过十分钟，他们可能就不再关注提交阶段通过与否了。 (查看原文) —— 引自第151页 -
长时间不提交代码会让合并工作变得过于复杂。 (查看原文) —— 引自第28页
作者: Jez Humble, David Farley
副标题: Reliable Software Releases through Build, Test, and Deployment Automation
isbn: 0321601912
书名: Continuous Delivery
页数: 512
定价: GBP 43.99
出版社: Addison Wesley
装帧: Hardcover
出版年: 2010-7-27