《持续交付》章节试读

《持续交付》的笔记-第115页

构建和部署的自动化

《持续交付》的笔记-第59页

Simian：识别代码重复的工具？？？

《持续交付》的笔记-第121页

Rake之后的新一代脚本化build工具：Buildr、Gradle、Gantt。

《持续交付》的笔记-第52页 - 3.5 必不可少的实践

......持续集成是一种实践，不是一个工具，它有效性依赖于团队纪律。要让持续集成系统能够发挥作用，尤其是面对一个大型复杂的持续集成系统时，整个开发团队就必须有高度的纪律性。......3.5.1 构建失败后不要提交新代码......3.5.2 提交前在本地运行所有的提交测试，或者让持续集成服务器完成此事......3.5.3 等提交测试通过后再继续工作......3.5.4 回家之前，构建必须处于成功状态.....并不建议工作到很晚修复失败的构建，而是希望你有规律地尽早提交代码，给自己足够的时间处理可能出现的问题。或者，你可以第二天在提交。很多有经验的开发人员在下班一小时内不再提交代码，而是把它作为第二天早上的第一件事情。如果所有手段不好使，那么把版本控制库中的代码回滚到上一次成功构建的状态，并在本地保留一份失败的代码就可以了。......3.5.5 时刻准备着回滚到前一个版本......3.5.6 在回滚之前要规定一个修复的时间......3.5.7 不要将失败的测试注释掉......3.5.8 为自己导致的问题负责......3.5.9 测试驱动的开发......

《持续交付》的笔记-第69页 - 测试策略的实现

在开发一个用户故事之前，就应该写好验收测试，采取完美的自动化形式。在敏捷环境中，验收测试至关重要，他回答了如下问题。对开发人员来说，他回答了“我怎么知道我做完了”，对于用户来说，他回答了“我得到了我想要的功能吗”我们现在的开发过程就使用了这样的方式，重视验收测试的重要性。已验收测试为标准，QA来写测试用例，并进行测试；开发已验收测试为标准来开发；这样就使得QA和开发在同一个标准上进行协同工作。如果QA发现有issue没有被包含的话，并不是直接开issue，而是增加Test Case，让开发基于Test Case开发新的功能。
这是一个很好的实践。事实证明也是很好用的流程，扯皮的事情也少了。

《持续交付》的笔记-第1页

本书中文站：
http://www.continuousdelivery.info

《持续交付》的笔记-第85页 - 第5章 5.1 引言

......从精益的角度来看，我们实现了一个 “拉式系统”（pull system），即测试团队只要自己单击按钮，就能将某个特定的软版本部署测试环境中。运维人员也可以通过单击一下按钮就把软件部署到试运行环境和生产环境中。在整个发布流程中，开发人员能看到每个目标环境上部署了哪个版本，发现了哪些问题。管理人员也很容易看到了一些关键的度量指标，比如周期时间（cycle time），吞吐量（throughput）以及代码质量等。......我们确信，这种方法能让我们以更高的质量和相当低的成本与风险来创建、测试、部署复杂系统。这正是部署流水线线的作用。

《持续交付》的笔记-第46页 - 持续集成

持续集成的前提条件：
1.频繁提交：频繁提交代码到版本控制库。
2.创建全面的自动化测试套件
3.保持较短的构建和测试过程
4.管理开发工作区

《持续交付》的笔记-第19页

持续集成系统的职责就是推翻这一假设，证明某个版本呢并不适合部署到生产环境中。Why?
原文是：Every change is, in effect, a release candidate. Every time a change is committed to version control, the expectation is that it will pass all of its tests, produce working code, and can be released into production. This is the starting assumption. The job of a continuous integration system is to disprove this assumption, to show that a particular release candidate is not fit to make it into production.

《持续交付》的笔记-第85页 - 5.2 什么是部署流水线

从某种抽象层次上讲，部署流水线是指软件从版本控制库到用户手中这一过程的自动化表现形式。对软件的每次变更都会经历一个复杂流程才能发布。这一流程包括构建软件，以及后续一系列不同阶段的测试与部署，而这些活动通常都需要多人或者多个团队之间的协作。部署流水线是对这一流程的建模，在持续集成和发布管理工具上，它体现为支持查看并控制整个流程，包括每次变更从被提交到版本控制库开始，直到通过各类测试和部署，再到发布给用户的过程。......要理解部署流水线以及代码变更在其上流动的方法，是把它看成一个序列图，如图5-2所示。□提交阶段是指从技术角度上断言整个系统是可以工作的。整个阶段会进行编译，运行一套自动化测试（主要是单元测试级别），并进行代码分析。□自动化验收测试阶段是从功能和非功能角度上断言整个系统是可以工作的，即从系统行为上看，它满足用户的需要并且符合客户的需求规范。□手工测试阶段用于断言系统是可用的，满足了它的系统要求，试图发现那些自动化测试未能捕获的缺陷，并验证系统是否为用户提供了价值。这一阶段通常包括探索性测试、集成环境上的测试以及UAT（User Acceptance Testing，用户验收测试）。□发布阶段旨在将软件交互给用户，即可能是以套装软件的形式，也可能是直接将其部署到生产环境，或者试运行环境（这里的试运行环境是指生产环境相同的测试环境）部署流水线就是由上述这些阶段，以及为软件交付流程建模所需的其他阶段组成，有时候也称为持续集成流水线、构建流水线、部署生产线或现行构建（living build）。无论把它叫做什么，从根本上讲，它就是一个自动化的软件交付流程。这并不是说该发布过程不需要人的参与，而是说在执行过程中那些易出错且复杂的步骤被变成可靠且可重复的自动化步骤。事实上，人工参与的活动反而有增加的趋势，因为在开发流程中所有阶段均可进行一键式部署这一事实，会促使测试人员、分析人员、开发人员以及（最重要的）用户更频繁地执行它。最基本的部署流水线图5-4中显示了一个典型的部署流水线，体现了这种方法的本质。当然，一个真正地流水线应该反映真实的软件交付流程。

《持续交付》的笔记-第39页

高效配置管理策略的两个基本原则是：
　　（1）将二进制文件与配置信息分离；
　　（2）将所有配置信息保存在一处。

《持续交付》的笔记-第4页 - 软件交付的问题

这种反模式的特征如下：
有一份非常详尽的文档，该文档描述了执行步骤及每个步骤中易出错的地方
我会告诉你我曾经天天写这种文档写到吐血吗？

《持续交付》的笔记-第107页 - 5.8 实现一个部署流水线

□对价值流建模，并创建一个可工作的简单框架□将构建和部署流程自动化；□将单元测试和代码分析自动化；□将验收测试自动化；□将发布自动化。

《持续交付》的笔记-第87页

部署流水线。。。哈哈

《持续交付》的笔记-第68页 - 4.2 测试的分类

测试有很多种。Brian Marick提出了如图4-1所示的测试象限，它被广泛的应用于为了确保交付高质量应用软件而做的各种类型的测试的建模。4.2.1 业务导向且支持开发过程的测试这一象限的测试通常被称作功能测试或验收测试。......系统的验收测试应该运行在类生产环境中。例如手工验收测试，它通常是将应用部署在用户验收测试（UAT)环境后进行的。......不过对于那些外部服务来说，我们可能会使用一些模拟（mock）技术。......自动化验收测试自动化验收测试有很多很有价值的特性。□它加快了反馈速度，因为开发人员可以通过运行自动化测试，来确认是否完成了一个特定需求，而不用去问测试人员。□它减少了测试人员的工作负荷。□它让测试人员集中精力做探索性测试和高价值的活动，而不是被无聊的重复性工作所累。□这些验收测试也是一组回归测试套件。......□就像行为驱动开发（BDD）所建议的那，使用人类可读的测试以及测试套件名，我们就可以从这些测试中自动生成需求说明文档。......回归测试也是一个特别重要的话题，在前面的象限图中并没有回归测试，因为它是跨象限的。回归测试是自动化测试的全集。......然而，自动化验收测试的维护成本可能很高。如果写的不好，它们会使交付团队付出极大的维护成本。......然而，通过使用正确的工具，并遵循好的实践原则，完全可以大大降低创建并维护自动化验收测试的成本，从而令收益大于付出。我们会在第8章讨论这些技术。同样需要记住的是，并不是所有东西都需要自动化。对于某些方面的测试来说，用手工方法做更好。易用性测试及界面一致性等方面很难通过自动化测试来验证。......一般我们将代码覆盖率高于80%的测试视为“全面的”测试，但测试质量也很重要，单单使用覆盖率这一指标是不够的。我们这里所说的测试覆盖率包括单元测试、组件测试和验收测试，每一种测试都应该覆盖应用程序的80%......作为对自动化验收测试覆盖率比较好的一种方法，可以考下面的情形：假设要替换系统中的某一部分（比如持久层，使用另一种实现来替换它）。当你完成替换时，进行了自动化测试，并且测试全部通过了。你有多大自信心，认为系统可以正常运行呢？一个好的自动化测试套件应该给你足够的信心进行重构，甚至对应用程序架构进行重构。而且，假如测试能全部通过，就证明应用程序的行为没有受到影响。......4.2.2 技术导向且支持开发过程的测试这些自动化测试单独由开发人员创建并维护。有三种测试属于这一分类：单元测试、组件测试和部署测试。......4.2.3 业务导向且评价项目的测试这类手工测试可以验证我们实际交付给用户的应用软件是否符合其期望。这并不只是验证应用是否满足需求规格说明书，还验证需求规格说明的正确性。......一种非常重要的面向业务且评价项目的测试是演示。在每个迭代结束时敏捷开发团队都向用户演示其开发完成的新功能。在开发过程中，我们也应该尽可能频繁地向客户演示功能，以确保尽早发现对需求规范的错误理解或有问题的需求规范。成功的演示既是福祉又是灾难，因为用户喜欢尝试新东西，但毫无疑问，他们会提出很多改进建议。......无论什么样的决定，更早的反馈总是比在项目快结束时才得到的反馈要好。......探索性测试......执行测试同时，测试人员会积极地控制测试的设计并利用测试时获得的信息设计新的更好的测试。......易用性测试是为了验证用户是否能很容易地使用该应用软件完成工作。......最后，可以让真正地用户使用你的系统进行beta测试。......4.2.4 技术导向且评价项目的测试验收测试分为两类：功能测试和非功能测试。非功能测试是指除了功能之外的系统其他方面地质量，比如容量、可用性、安全性等。......4.2.5 测试替身自动化测试的一个关键是在运行时用一个模拟对象来替代系统中的一部分。这样应用程序中被测试的那部分与系统其他部分之间的交互可以被严格地掌控，从而更容易确定应用程序中这一特定部分的行为。这样的模拟对象常常就是mock、stub和dummy等。我们所使用的术语来自Gerard Meszaros的xUnit Tet Patterns一书，是由Martin Fowler总结出来的。Meszaros为其定义了术语“测试替身”（test double），并进一步区分了各种测试替身。□呀对象（dummy object）是指那些被传递但不被真正使用的对象。通常这些哑对象只是用于填充参数列表。□假对象（fake object)是可以真正使用的实现，但是通常会利用一些捷径，所以不适合在生产环境中使用。一个很好的例子是内存数据库。□桩（stub）是在测试中为每个调用提供一个封装好的响应，它通常不会对测试之外的请求进行响应，只用于测试。□模拟对象（mock）是一种在编程时就设定了它预期要接收的调用。如果收到了未预期的调用，他们会抛出异常，并且还会在验证时被检查是否收到了他们所预期的所有调用。......关于mock和stub之间的不同之处超出了本书的讲述范围，但我们仍会在第8章讲到一些相关内容。关于如何正确使用mock最详尽的文章应该算是“Mock Roles, Not Objects”。......

《持续交付》的笔记-第20页

提前并频繁地做让你感到痛苦的事。

《持续交付》的笔记-第91页 - 5.3 部署流水线的相关实践

5.3.1 只生成一次二进制包......总之，二进制包应该只在构建流水线的提交阶段生成一次。这些二进制包应该保存在文件系统的某个位置上，让流水线的后续阶段能够轻松地访问到这个位置，但要注意不要放在版本控制库中，因为它只是一个版本的衍生品，并不是原生态的定义。......5.3.2 对不同环境采用同一部署方式......5.3.3 对部署进行冒烟测试......5.3.4 向生产环境中的副本中部署......另一种构建策略是，一旦代码构建和单元测试结束，持续集成系统就去检查版本库中是否有新的提交。如果有的话，就将最近还没有构建过的所有变更全部拿来进行构建......5.3.6 只要有环节失败，就停止整个流水线......

《持续交付》的笔记-第7页

将测试、部署和发布活动也纳入到开发过程中，让它们成为开发流程正常的一部分。确保每个人都成为这个软件交付过程的一份子，无论是构建发布团队、还是开发测试人员，都应该从项目开始就一起共事。你应该具有重建生产环境的能力，最好是能通过自动化的方式重建生产环境。

《持续交付》的笔记-第104页 - 5.7 发布准备

□让参与项目交付过程的人共同创建并维护一个发布计划（包括开发人员和测试人员，以及运维人员，基础设施和支持人员）；□通过尽可能多的自动化过程最小化人为错误发生的可能性，并从最容易出错的环节开始实现自动化；□在类生产环境中经常做发布流程演练，这样就可以对这个流程及其所使用的技术进行调试；□如果事情并没有按计划执行，要有撤销某次发布的能力；□作为升级和撤销过程的一部分，制定配置迁移和数据迁移的策略。......5.7.1 自动部署与发布对于生产环境的控制权越小，遇到意外情况的可能性就越大。......5.7.2 变更的撤销......5.7.3 在成功的基础上构建当一个候选发布版本能够部署到生产环境时，我们就确信：□代码可以编译；□代码能够按开发人员的预期运行，因为它通过了单元测试；□系统能够满足分析人员或用户预期，因为它通过了所有的验收测试；□基础设施的配置和基线环境被恰当地管理了，因为应用程序在模拟的生产环境上通过了测试；□系统所有的正确组件都就绪了，因为它是可以部署的；□部署脚本也是可以工作的，因为在该版本到这一阶段之前，部署脚本至少在开发环境中用过一次，在验收测试阶段用过一次，在测试环境中用过一次；□我们需要部署的所有内容都在版本控制库中，而且不需要手工干预，因为我们已经部署这个系统好几次了。这种“在成功的基础上构建”的方法，完全符合我们常挂在嘴边的口头禅“尽快让整个流程或其任何环节失败”，这在任何层次都是有用的。

《持续交付》的笔记-第112页 - 5.9 度量

尽管周期时间是软件交付中最重要的度量项，但还有一些其他度量项可以对问题起到报警作用。这些度量项如下所示。□自动化测试覆盖率。□代码库的某些特征，比如重复代码量、圈复杂度、输入耦合度、输出耦合度、代码风格问题等。□缺陷的数量。□交付速度，即团队交付可工作、已测试过并可以使用的代码的速率。□每天提交到版本控制库的次数。□每天构建的次数。□每天构建失败的次数。□每次构建所花的时间，包括自动化测试的时间。......

《持续交付》的笔记-第121页

像Make一样，Rake只能理解任务和依赖。
确实，作为一个自动化build工具，只需要理解任务和依赖就行。

《持续交付》的笔记-第44页 - 3.2 实现持续集成

3.2.1 准备工作1. 版本控制......2.自动化构建......3.团队共识......3.2.2 一个基本的持续集成系统为了做持续集成，你不一定就需要一个持续集成软件，正如我们所说，它是实践，并不是工具。......一旦准备好要提交最新修改代码时，请遵循如下步骤。（1）查看一下是否有构建正在进行。如果有的话，你要等它运行完。如果它失败了，你要与团队中的其他人一起将其修复，然后提交自己的代码。（2）一旦构建完成且测试全部通过，就从版本控制库中将该版本的代码更新到自己的开发环境上。（3）在自己的开发机上执行构建脚本，运行测试，以确保在你机器上的所有代码都工作正常。当然你也可以利用持续集成工具中的个人构建功能来完成这一步骤。（4）如果本地构建成功，就将你的代码提交到版本控制库中。（5）然后等待包含你的这次提交的构建结果。（6）如果这次构建失败了，就停下手中所做的事，在自己的开发机上立即修复这个问题，然后再转到步骤（3）。（7）如果这次构建成功，你可以小小地庆祝一下，并开始下一项任务。如果团队中的每个人在每次提交代码时都能够遵循这些简单的步骤，你就可以很有把握地说：“只要是在与持续集成一模一样的环境上，我的软件就可以工作。”

《持续交付》的笔记-第55页

如果某此提交失败了，无论采取什么样的行动，最重要的是尽快让一切再次正常运转起来。

《持续交付》的笔记-第28页

长时间不提交代码会让合并工作变得过于复杂。

《持续交付》的笔记-第5页 - 一些常见的发布反模式

以上几点引起的一个必然结果：手工部署过程依赖于部署专家。如果专家去度假或离职了，那你就有麻烦了。
尽管手工部署枯燥且极具重复性，但仍需要有相当程度的专业知识。若要求专家做这些无聊、重复，但有技术要求的任务则必定会出现各种我们可以预料到的人为失误，同时失眠，酗酒这种问题也接踵而来。
基本上就是我血淋淋的历史以及没有酗酒。。。。（感觉没有跟上大家的脚步

《持续交付》的笔记-第44页 - 持续集成

持续集成的准备工作：
1.版本控制：与项目相关的所有内容都必须提交到一个版本控制库中，包括产品代码、测试代码、数据库脚本、构建与部署脚本，以及所有用于创建、安装、运行和测试应用程序的东西。
2.自动化构建：要能在命令行中启动构建过程。必须满足如下条件：人和计算机都能通过命令行自动执行应用的构建，测试以及部署过程。
3.团队共识：持续集成不是一种工具，而是一种实践。需要开发团队能够给予一定的投入并遵守一些准则。

《持续交付》的笔记-第34页

实例化需求说明并不以程序员为中心，而程序员独自使用一个工具不会取得很好的效果。

《持续交付》的笔记-第18页

开发人员对代码库的每次修改都应该是以某种方式为系统增加价值。每次代码到版本控制系统的提交都应该是对当前所开发软件的提高或增强。我们如何知道它的正确性呢？唯一的方法就是运行这个软件，看它的行为是否符合我们的期望。大多数项目都将这部分工作推迟到了开发的后期。这就意味着，即使它不能工作，也只有当有人测试或使用这个软件时才能发现，而此时的修复成本通常会比较高。这个阶段通常称作集成阶段，常常是整个开发过程中最不可预测、最不易管理的阶段。由于集成这件事太痛苦了，所以团队总是推迟集成工作。然而，集成频率越低，集成时我们就会越痛苦。如果在软件开发中的某个任务令你非常痛苦，那么解决痛苦的方法只有更频繁地去做，而不是回避。

《持续交付》的笔记-第37页 - 2.4.5 管理配置信息的原则

2.4.5 管理配置信息的原则我们要把应用程序的配置信息当做代码一样看待，恰当地管理它，并对它进行测试。当创建应用程序的配置信息时，应该考虑以下几个方面。 □在应用程序的生命周期中，我们应该在什么时候注入那些配置信息。......要与系统运维和支持团队一同讨论，看看他们有什么样的需求。 □将应用程序的配置项与源代码保存在同一个存储库中，但要把配置项的值保存在别处。...... □应该总是通过自动化的过程将配置项从保存配置信息的存储库中取出并设置好..... □配置系统应该能依据应用、应用软件的版本、将要部署的环境，为打包、安装以及部署脚本提供不同的配置值。...... □对每个配置项都应用明确的命名习惯，避免使用晦涩难懂的名称，...... □确保配置信息是模块化且封闭的，...... □DRY（Don't Repeat Yourself）原则。...... □最少化，即配置信息应尽可能简单且集中。...... □避免对配置信息的过分设计，应尽可能简单。 □确保测试已覆盖到部署或安装时的配置操作。......

《持续交付》的笔记-第120页

Maven每次执行都会尝试更新自己？这会导致build可能失败。Ivy给Ant增加了包依赖管理的能力。
C# .Net下，MSBuild是基于NAnt开发的工具。。。

《持续交付》的笔记-第37页 - Chapter 1: The problem of delivering software

The value stream of delivering software:
requirement - design - development - testing
build - deploy - test -release
The teams involved in delivering the value:
developer - tester - build engineer - operation
repeatable build in theory is possible, but since we use a lot of tools's release link, which change over time - that means we are not able to reproduce a prior build which the exact same toolchain, hopefully those tools are backward compatible.

《持续交付》的笔记-第9页 - 1.3 如何实现目标

......我们及我们的同事发现，为了达到这些目标（短周期、高质量），我们需要频繁且自动化地发布软件。......对于频繁地自动化发布来说，反馈是至关重要的。下面关于反馈的三个标准是很有用的：□无论什么样的修改都应该触发反馈流程；□反馈应该尽快发出；□交付团队必须接收反馈，并依据它作出相应的行动。1.3.1 每次修改都应该触发反馈流程......1.3.2 必须尽快接收反馈......1.3.3 交付团队必须接收反馈并作出反应......

《持续交付》的笔记-第46页 - 3.3 持续集成的前提条件

3.3.1 频繁提交对于持续集成来说，我们最重要的工作就是频繁提交代码到版本控制库。每天至少应该提交几次代码。....前面我们特意提到过“要提交到主干”。很多项目使用版本控制中的分支技术来进行大型团队的管理。然而，当使用分支时，其实不可能真正地做到持续集成。因为如果你再分支上工作，那么你的代码就没有和其他开发人员的代码进行即时集成。除一些很有限的情况外，我们不推荐使用分支。......3.3.2 创建全面的自动化测试套件....自动化测试有很多种，我们会在下一章详细讨论。其中有三类测试我们会在持续集成构建中使用，他们分别是单元测试、组件测试和验收测试。单元测试用于单独测试应用程序中某些小单元的行为（比如一个方法、一个函数，或一组方法或函数之间的交互）。它们通常不需要启动整个应用程序就可以执行，而且也不需要连接数据库（如果应用程序需要数据库的话）、文件系统或网络。单元测试应该运行得非常快，即使对于一个大型应用来说，整个单元测试套件也应该在十分钟之内完成。组件测试用户测试应用程序中几个组件的行为。与单元测试一样，它通常不必启动整个应用程序，但有可能需要连接数据库、访问文件系统或其他外部系统或接口（这些可以使用“桩”，即stub技术）。组件测试的运行时间通常较长。验收测试的目的是验证应用程序是否满足业务需求所定义的验收条件，包括应用程序提供的功能，以及其他特定需求，比如容量、有效性、安全性等。验收测试最好采用将整个应用程序运行于类生产环境的运作方式。当然，验收测试的运行时间也比较长。一个验收测试套件连续运行一整天是很平常的事儿。通过组合使用这三类测试，你就能确信引入的修改不会破坏任何现有功能。3.3.3 保持较短的构建和测试过程......XUnit类型的工具，比如JUnit和NUnit，可以提供每个测试运行时长的报告。找出那些运行较慢的测试，看看是否可以把它们优化一下，或者在确保同样覆盖率和信心的前提下缩短测试时间。这样的事情应该经常做。

《持续交付》的笔记-第1页

刚刚开始

《持续交付》的笔记-第75页 - 4.3 现实中的情况与应对策略

4.3.1 新项目新项目......变化的成本比较低，通过建立一些相对简单的基本规则，并创建一些相对简单的测试基础设施，就可以很顺利地开始你的持续集成之旅。在这种情况下，最重要的事情就是一开始就要写自动化验收测试。为了能做到这一点，你需要：□选择技术平台和测试工具□建立一个简单的自动化构建□制定遵守INVEST原则[即独立的（Independent）、可协商的（Negotiable）、有价值的（Valuable）、可估计的（Estimable）、小的（Small）且可测试的（Testable）]的用户故事及考虑其验收条件。然后就可以严格遵守下面的流程：□客户、分析师和测试人员定义验收条件□测试人员和开发人员一起基于验收条件实现验收测试的自动化；□开发人员编码来满足验收条件；□只要有自动化测试失败，无论是单元测试、组件测试还是验收测试，开发人员都应该把它定为高优先级并修复它。......4.3.2 项目进行中......4.3.3 遗留系统......4.3.4 集成测试

《持续交付》的笔记-第43页 - 3.1 引言

持续集成要求每当有人提交代码时，就对整个应用进行构建，并对其执行全面的自动化测试集合。而且至关重要的是，假如构建或测试过程失败，开发团队就要停下手中的工作，立即修复它。持续集成的目标是让正在开发的软件一直处于可工作状态。

《持续交付》的笔记-第19页 - 1.6 软件交付的原则

......1.6.1 为软件的发布创建一个可重复且可靠的过程......这种可重复性和可靠性来自于以下两个原则：（1）几乎将所有事情自动化；（2）将构建、部署、测试和发布软件所需的东西全部纳入到版本管理之中。归根结底，软件部署包括三件事：□提供并管理你的软件所需要的运行环境，这包括硬件配置、所依赖的软件、基础设施以及所需的外部服务；□将你的应用程序的正确版本安装在其之上；□配置你的应用程序，包括它所需要的任何数据及状态。......1.6.2 将几乎所有事情自动化......1.6.3 把所有的东西都纳入版本控制......1.6.4 提前并频繁地做让你感到痛苦的事......1.6.5 内建质量这一原则和上一原则（持续改进）都是从精益运动（lean movement）中借鉴来的。“内建质量"也是戴明（精益运动的先驱之一）提出的名言之一。越早发现缺陷，修复它们的成本越低。......“内建质量”还有另外两个推论。（1）测试不是一个阶段，当然也不应该开发结束之后才开始。......（2）测试也不纯粹或主要是测试人员的领域。交付团队的每个人都应该对应用程序的质量负责。1.6.6 “DONE”意味着“已发布”......根本没有“已完成了80%”这一说法。任何事情要么是完成了，要么就是没完成。......1.6.7 交付过程是每个成员的责任......这是DevOps运动的核心原则之一。DevOps运动的焦点和我们这本书的目标一致：为了更加快速且可靠地交付有价值的软件，鼓励所有参与软件交付整个过程中的人进行更好的写作。1.6.8 持续改进......应用程序的首次发布只是其生命周期中的第一个阶段。.......戴明环：计划-执行-检查-处理（PDCA）。......

《持续交付》的笔记-第8页

如果部署失败，可以在相同短的时间内回滚。
——我觉得对于一般的Web系统实现而言，要做到这一点实际上需要在产品环境同时运行2个最近的版本，然后有一个快速的switch过程。。。

《持续交付》的笔记-第97页 - 5.4 提交阶段

......提交阶段就能够在一个可接受的时间之内完成（最好在五分钟之内完成，最多不能超过十分钟）。一般来说提交阶段包含以下步骤：□编译代码（如果所用开发语音需要的话）；□运行一套提交测试；□为后续阶段创建二进制包；□执行代码分析来检查代码的健康状况；□为后续阶段做准备工作，比如准备一下后续测试所用的数据库。......接着，运行一套测试集合。最好优化一下，让它运行得飞快。之所以把这一套测试称为提交阶段的测试而不是单元测试。......测试非功能特性（比如容量）可能比较困难，但仍旧可通过一些分析工具，收集一些关于当前代码库的测试覆盖率、可维护性以及安全漏洞方面的信息。为这些度量项设定一个阀值，并像对待测试一样，一旦不满足阀值条件，就让提交阶段失败。比较有用的度量项包括：□测试覆盖率；□重复代码的数量；□圈复杂度（cyclomatic complexity）；□输入耦合度（afferent coupling）好输出耦合度（efferent coupling）；□编译警告的数量□代码风格......

《持续交付》的笔记-第73页

虽然用户很少花时间提前对容量和安全性做要求，但一旦他们的信用卡信息被盗，或者网站由于容量问题总是停止运行，他们就会非常生气。

《持续交付》的笔记-第115页 - 第6章 构建与部署的脚本化

6.2 构建工具概览......所有构建工具都有一个共同的核心功能，即可以对依赖关系建模。......一个值得注意的小地方是每个任务都包括两点内容，一是它做什么，二是它依赖于什么。在每个构建工具中都会对这两点进行建模。......6.2.1 Make6.2.2 Ant6.2.3 NAnt与MSBuild6.2.4 Maven6.2.5 Rake6.2.6 Buildr......如果刚开始一个Java项目，或是想找Ant或Maven的替代品，我们强烈推荐Buildr，如果你喜欢Groovy中的DSL，就用Gradle吧。6.2.7 Psake6.3 构建部署脚本化的原则与实践6.3.1 为部署流水线的每个阶段创建脚本我们是DDD（Domain-Driven Design，领域驱动设计）的忠实粉丝。......6.3.2 使用恰当地技术部署应用程序6.3.3 使用同样的脚本向所有环境部署6.3.4 使用操作系统自带的包管理工具6.3.5 确保部署流程是幂等的（Idempotent）6.3.6 部署系统的增量式演进6.4 面向JVM的应用程序的项目结构6.5 部署脚本化6.5.1 多层的部署和测试6.5.2 测试环境配置6.7 小结......最后，再重申一次，脚本应该是系统中的“一等公民”。这些脚本应该贯穿应用程序的整个生命周期。我们应该对这些脚本进行版本控制、维护、测试和重构，并将其作为部署应用程序的唯一机制。

《持续交付》的笔记-第3页 - 1.2 一些常见的发布反模式

1.2.1 反模式：手工部署软件......1.2.2 反模式：开发完成之后才向类生产环境部署......1.2.3 反模式：生产环境的手工配置管理......

《持续交付》的笔记-第29页

无论提交注释写得多么短小精悍，你也得不到奖励。然而，多写几行字来描述你做了什么，会为将来节省很多时间。

《持续交付》的笔记-第137页 - 第7章 提交阶段

7.1 引言......当某人向版本控制库的主干上提交了一次变更后，持续集成服务器会发现这次变更，并将代码签出，执行一系列的任务，包括：□编译（如果需要的话），并在集成后的源代码上运行提交测试；□创建能部署在所有环境中的二进制包......；□执行必要的分析，检查代码库的健康状况；□创建部署流水线的后续阶段需要使用的其他产物（比如数据库迁移或测试数据）。......7.2 提交阶段的原则和实践7.2.1 提供快速有用的反馈7.2.1 何时令提交阶段失败7.2.3 精心对待提交阶段7.2.4 让开发人员也拥有所有权7.2.5 在超大项目团队中指定一个构建负责人7.3 提交阶段的结果与部署流水线的所有阶段一样，提交阶段即有输入也有输出。输入是源代码，输出是二进制包和报告。产生的报告包括测试结果（假如测试失败，这些结果是找出哪里出了错的重要信息）和代码库的分析报告。分析报告可能包括测试覆盖率、圈复杂度、复制/粘贴分析、输入和输出耦合度以及其他有助于建立健康代码库的度量项。......7.4 提交测试套件的原则与实践7.4.1 避免用户界面......对于提交测试来说，我们建议根本不要通过用户界面进行测试。......通常最好由部署流水线的验收测试阶段处理。7.4.2 使用依赖注入......7.4.3 避免使用数据库......7.4.4 在单元测试中避免异步......7.4.5 使用测试替身......对于大型组件和子系统的模拟，我们倾向于使用桩技术。但是，对于模拟编程语言级的组件，我们建议少用桩技术，更推荐使用模拟技术。......使用模拟技术，你就可以说：“给我构建一个对象，让它假装就是某某类型的一个类。”关键是，还可以更近一步，在一些简单的断言中，你能指定测试中期望该模拟类作出什么行为。这是模拟技术和桩技术的根本不同。使用桩时，我们不需要关心桩是如何被调用的，而使用模拟对象时，可以验证我们的代码是否以期望的方式与模拟对象进行交互。......7.4.6 最少化测试中的状态......7.4.7 时间的伪装......7.4.8 蛮力......有两招儿能加快测试套件的运行。首先，将它分成多个套件，在多台机器上并行执行这些套件。时新的持续集成服务器都有“构建网格”功能，直接支持这种做法。记住，计算能力是廉价的，而人力是昂贵的。及时得到反馈比准备几台服务器的成本要有价值的多。第二招儿就是，作为构建优化过程的一部分，将那些运行时间比较长且不经常失败的测试放到验收测试阶段运行。然而需要注意的是，这会导致需要更长的时间才能知道这些测试是否失败了。7.5 小结提交测试应该聚焦于一点，即尽快地捕获那些因修改向系统中引入的最常见错误，并通知开发人员，以便他们能快速修复它们。提交阶段提供反馈的价值在于，对它的投入可以让系统高效且更快地工作。......

《持续交付》的笔记-第57页 - 3.6 推荐的实践

3.6.1 极限编程开发实践......3.6.2 若违背架构原则，就让构建失败......3.6.3 若测试运行变慢，就让构建失败......为了让开发团队注意到快速测试的重要性，可以这样做：当某个测试运行超过一定时间后，就让这次提交测试失败。......补充一点，这个实践是一柄“双刃剑”。......3.6.4 若有编译警告或代码风格问题，就让测试失败......代码质量检查的开源工具：Simian、JDepend、CheckStyle、FindBugs............我们通常会渐进式地引入这种实践，将编译警告的个数或者TODOs的个数与前一次提交中的个数进行比较。如果个数增加，我们就让构建失败。......

《持续交付》的笔记-第6页

对于一个Web系统运行环境而言，最好是在html footer部分插入系统的build信息（这就相当于桌面软件的About信息框了），这样可以随时看到SCM build版本对应的UI功能差别

《持续交付》的笔记-第15页

请将配置信息放在版本控制系统中。这个最简单的动作就是一个巨大的进步。

《持续交付》的笔记-第50页 - 3.4.2 铃声和口哨

......还有一种方式是使用TTS语音合成技术（从文本到语音的转换）读出令构建失败的提交人的名字。......

《持续交付》的笔记-第42页 - 2.6 小结

配置管理是本书其他内容的基础。没有配置管理，根本谈不上持续集成、发布管理以及部署流水线。