持续交付+发布可靠软件的系统方法

说明：
反模式：不建议的方法。

第1章　软件交付的问题　
1.1
无

1.2
1.2.1 反模式：手工部署软件
随着时间的推移，部署应该走向完全自动化，即对于那些负责将应用程序部署到开发环境、测试环境或生产环境的人来说，应该只需要做两件事：(1)挑选版本及需要部署的环境，(2)按一下“部署”按钮。对于套装软件的发布来说，还应该有一个创建安装程序的自动化过程。

1.2.2 反模式：开发完全完成之后才向生产环境部署

1.2.3 反模式：生产环境手工配置管理？

1.3目标

为了达到这些目标(短周期、高质量)，我们需要频繁且自动化地发布软件：

1.自动化。如果构建、部署、测试和发布流程不是自动化的，那它就是不可重复有用的的。由于软件本身、系统配置、环境以及发布过程的不同，每次做完这些活动以后，其结果可能都会有所不同。由于每个步骤都是手工操作，所以出错的机会很大，而且无法确切地知道具体都做了什么。这意味着整个发布过程无法得到应有的控制来确保高质量。常常说软件发布像是一种艺术，但事实上，它应该是一种工程学科。
2.频繁做。如果能够做到频繁发布，每个发布版本之间的差异会很小。这会大大减少与发布相关的风险，且更容易回滚。频繁发布也会加快反馈速度，而客户也需要它。本书很多内容都聚焦于如何尽快得到对软件及其相关配置所做变化的反馈，这包括其环境、部署过程及数据等。

对于频繁地自动化发布来说，反馈是至关重要的。下面关于反馈的三个标准是很
口无论什么样的修改都应该触发反馈流程；
口反馈应该尽快发出；
口交付团队必须接收反馈，并依据它作出相应的行动。

1.3.1 每次修改都应该触发反馈流程

一个可工作的软件可分成以下几个部分：可执行的代码、配置信息、运行环境和数据。

1.3.1 必须尽快接受反馈

1.4收效
 测试人员可以选择性地部署较旧的版本，以验证新版本上的功能变化。
 技术支持人员可以自己部署某个已发布的版本，用于重现缺陷。
 作为灾难恢复手段，运维人员可以自己选一个已知的正确版本，将其部署到生产环境中。
 发布方式也变成一键式的了。

现在，让我们来设想一下。如果接下来的发布只需要单击一下按钮，而且只需要等上几分钟，甚至几秒钟内就可以完成。另外，假如发生了非常糟糕的事情，你只要花上相同的几分钟或几秒钟的时间就可以把刚部署的内容恢复到从前的老样子。再大胆地设想一下，假如你的软件发布周期总是很短，那么当前生产环境中的版本与新版本之间的差异应该非常小。如果上述设想都是事实的话，那么发布的风险一定会大大降低，那种将职业生涯压注在发布是否成功的不爽感觉也将大大减少。

1.4.5 多加练习，使其完美
最好的策略就是无论部署到什么样的目标环境，都使用相同的部署方法。不应该有特殊的QA部署策略，或者一个特殊的验收测试或生产部署策略。在每次以同一种方式部署应用软件时，也是验证我们的部署机制是否正确的时机。事实上，向其他任何环境的任何一次部署过程都是生产环境部署的一次演练。

1.5 候选发布版本？

1.6 软件交付原则
1.6.1　为软件的发布创建一个可重复且可靠的过程　
1.6.2　将几乎所有事情自动化　
1.6.3　把所有的东西都纳入版本控制　
1.6.4　提前并频繁地做让你感到痛苦的事　
1.6.5　内建质量　
1.6.6　“DONE”意味着“已发布”　
1.6.7　交付过程是每个成员的责任　
1.6.8　持续改进　

归根结底，软件部署包括三件事：
-提供并管理你的软件所需要的运行环境，这包括硬件配置、所依赖的软件、基础设施以及所需的外部服务；
-将你的应用程序的正确版本安装在其之上；
-配置你的应用程序，包括它所需要的任何数据以及状态。

第2章　配置管理

假如项目中有良好的配置管理策略，那么你对下列所有问题的回答都应该是“YES”：
-你能否完全再现你所需要的任何环境(这里的环境包括操作系统的版本及其补丁级别、网络配置、软件堆栈，以及部署在其上的软件应用及其配置)?
-你能很轻松地对上述内容进行增量式修改，并将修改部署到任意一种或所有环境中吗?
-你能否很容易地看到已被部署到某个具体环境中的某次修改，并能追溯到修改源，知道是谁做的修改，什么时候做的修改吗?
-你能满足所有必须遵守的法规吗?
-是否每个团队成员都能很容易地得到他们所需要的信息，并进行必要的修改呢?这个配置管理策略是否会妨碍高效交付，导致周期时间增加，反馈减少呢?