高度自动化(一)-发布可靠软件的系统方法一书

对项目的度量标准

软件发布应该是一个快速且可重复的过程（因为很可能一天发布几次）

对项目的度量标准： 
涉及一行代码的改动需要花多长时间才能部署上线？

从决定做某种修改 到 该修改结果正式上线 即周期时间是多长？

部署流水线

常见的发布反模式

• 手动部署

缺点： 容易发生人为错误

• 生产环境的手工配置管理

原则

 不应该允许手动改变测试环境，试运行环境和生产环境，只允许通过自动化过程来改变这些环境

  部署出错时，最短时间内自动化回滚到之前的版本

 快速交付。问题修复或新功能上线

 反馈流程

指完全以自动化方式尽可能测试每一次变更。 根据系统不同，测试会有不同，但至少包括以下测试：


验证源代码是否符合语法，如sonar检查等
单元测试必须成功
必须满足一定的质量标准，如测试覆盖率(75%左右的代码库覆盖率，只有这样，才对写的软件比较有信心)及其他相关的度量项
功能测试必须成功
非功能测试是必须的：对性能，有效性，安全性等要求
必须通过探索性测试
回归测试：可以写自动化测试来避免回归测试
其他（配置，数据库）


通过版本控制库管理所有可能的变动内容： 配置文件，创建数据库的脚本，构建脚本，测试用具，甚至开发环境和操作系统的配置
注意：

如何评价测试环境？
快速部署和回滚任意版本；
整个部署的时间
数据库和测试环境与生产环境的差异
发布一键
评估上下游系统的整个影响和依赖
隔离上下游的程度

缓解压力

压力本身是问题的根源。

例如 ：

 
“都这个时候了，就不能直接修改一下代码吗” 或者 让DBA直接导入一些来路不明的数据到生产数据库表中。

这里的问题在于： 上线时一个非常重大的事件，可以通过以下手段解决：
一键发布；
快速回滚

开发后再做测试，无疑会降低软件的质量

问题发现的越晚，修复的代价越高。

软件交付的原则

为软件的发布创建一个可重复且可靠的过程：

几乎将所有事情自动化；
将构建，部署，测试和发布所需要的所有东西纳入到版本控制管理中
内建质量
越早发现缺陷，修复的成本越低。 如果在代码提交到git,svn前，发现并修复的代码就很小。
内建质量的推论：
（1）测试不是一个阶段，当然也不应该开发结束后才开始。 如果把测试留到最后，那就晚了， 因为很可能根本没有时间修复那些刚被发现的问题

（2）测试也不纯粹或主要是测试人员的领域。交付团队的每个人都应该对应用的质量负责。

“DONE”意味着“已发布”

根本没有“已经完成了80%”这一说法。 任何事情要么完成了，要么就是没有完成。可以估计尚未完成的某件工作还需要多少工作量，单这也是仅仅估计而已。
但有一个事实： 一件事情的完成与否，并不是一个人能控制的了得，它需要整个 交付团队共同完成。这就是为什么所有人（开发，测试，运维，技术支持人员）在项目一开始就应该一起工作。这就是为什么整个交付团队应该对交付负责。

交付过程是每个成员的责任

理想情况下，每个成员有共同的目标，并且每个成员应在工作中户型帮助来实现这一目标。 无论成功还是失败，其结果都属于这个团队，非个人。
现实中的很多项目都是开发人员开发后将困难交个测试人员，而测试人员又在发布时将困难转嫁给运维团队，有问题时，花费大量的时间来修复错误，并用同等的时间来互相指责。

打破角色直接的壁垒

从一个项目的开始就要保证团队成员能够一起参与到发布程序的过程中，来保证他们有机会频繁且有规律的进行交流。比如，有一个系统，在这个系统上，每个人都可以一眼就知道应用程序所处的状态，如健康状况，各个构建版本，构建通过了哪些测试，可被部署到的环境的状态。
  为了更快且可靠交付有价值的软件，鼓励所有参与软件交付整个过程中的人进行更好的协作。