1. 部署行为是系统生命的重要组成部分

1.1. 只编写代码是不够的，只要没有在生产环境中运行，一切都不算完成

1.2. 要想取得成功，需要早早地频繁部署软件

1.3. 设计易于部署的软件非常有必要

1.4. 零停机部署就是目标

2. 机器与服务

2.1. 机器是可配置的操作系统实例

2.1.1. 如果系统在真正的机器上运行，那么这就意味着物理主机

2.1.2. 如果系统在虚拟机、容器或unikernel上运行，那么这些就是单元

2.2. 服务是供其他系统使用的可调用接口

2.2.1. 由在多台机器上运行的软件的冗余副本组成

2.3. 我们的环境拥有比以往更多的机器，而且大部分都是虚拟的

2.4. 有些机器是其他机器创建的，所以运维人员从未接触

3. 计划停机时间的谬误

3.1. 不能计划一次或几次就完成部署，而应该每次一点逐步叠加地进行多次部署

3.2. 更新系统的过程需要花费时间

3.3. 要将部署视为软件的一个特性

3.3.1. 不能只为了最终状态而编写代码，然后将代码交给运维部门，让他们搞清如何在生产环境中运行这些程序

4. 自动化部署

4.1. 构建流水线

4.1.1. 将代码变更提交到版本控制系统后，构建流水线就会启动

4.1.2. 产品

4.1.2.1. Jenkins可能是如今最常用的工具

4.1.2.2. ThoughtWorks的GoCD

4.1.2.3. Netflix公司的Spinnaker

4.1.2.4. 亚马逊的AWS Code Pipeline

4.2. 不要试图去找最好的工具，而应该选择一个足够满足需要的，然后好好加以利用

4.3. 由于服务可以在具有不同IP地址的任意数量的不同机器上运行，因此平台还必须配置网络，实现负载均衡和流量路由

4.4. 如果使用不可变的基础设施，那么一般从基本的操作系统镜像开始部署

4.4.1. 此时并不是试图从未知状态收敛到预期状态

4.4.2. 始终从已知状态——主操作系统镜像——开始

4.5. 不可变的基础设施与IaaS、PaaS以及自动化映射是高度一致的

4.6. 状态收敛在物理机器部署、长寿命虚拟机器和手动映射中则更为常见

5. 持续部署

5.1. 未部署的代码

5.1.1. 未完成的库存

5.1.2. 有着未知的缺陷

5.1.3. 会令容量扩展失效

5.1.4. 会导致生产环境出问题

5.1.5. 也可能很好地实现一个没人想要的功能

5.2. 从开发人员向代码库提交代码到代码最终在生产环境中运行，这段时间的代码最为棘手

5.2.1. 持续部署就是尽可能地缩短上述时间段，尽可能地减少未部署代码引发的问题

5.3. 持续不间断地部署所有代码

5.3.1. 意味着每次提交代码，都要运行完整的构建流水线

5.4. 如果放慢软件发布进度耗费的成本，超过部署软件中弥补错误需要的成本，那么通过流水线自动将代码部署到生产环境更合适

5.5. 由代码错误造成的成本，可能会远远大于在竞争中较慢地发布软件的成本，此时在部署到生产环境之前进行人工检查更为合理

5.5.1. 要确保掌管授权按钮的人能随时待命

6. 部署中的各个阶段

6.1. 部署PHP应用程序，就是简单地把文件复制到生产主机上，然后下一个访问该主机的请求就会访问这些新文件

6.1.1. 当请求访问尚未完成复制的文件时，该如何处理

6.2. 相比复制软件包文件并重新启动应用程序容器，复制没有运行时进程的单个文件速度更快

6.3. 粒度越大，安装和激活软件所需的时间就越长

6.4. 微观时间尺度适用于单个实例（主机、虚拟机或容器）

6.5. 宏观时间尺度适用于这个版本的整体推送

6.6. 对于可变的基础设施，这意味着将文件复制到位，从而能够快速更新符号链接或目录引用

6.7. 对于不可变的基础设施，这就是部署新镜像所需的时间

6.8. 会话可以保持活动的时间长度可以没有上限，特别是当你无法区分访问者是人类还是机器人或网络爬虫的时候，尤其如此

6.9. 一旦将部署视为一段时间内的工作，就可以让应用程序协助完成自身的部署

7. 关系数据库模式

7.1. 完全安全的数据库模式的变更是

7.1.1. 添加一个表格

7.1.2. 添加视图

7.1.3. 在表中添加一个可空列

7.1.4. 添加别名或同义词

7.1.5. 添加新的存储过程

7.1.6. 添加触发器

7.1.7. 将现有数据复制到新的表格或列中

7.1.8. 数据库模式变更的扩充阶段

7.1.8.1. 当前应用程序不会使用这些变更中的任何内容

7.2. 垫片

7.2.1. 一些有助于连接应用程序旧版本和新版本的代码

7.3. 对测试来说，除了支持前滚，最好也要支持回滚

7.4. 不要忘记在真实的数据样本上测试数据库的模式变更

7.5. 测试时绝对不要依赖应用程序当前所谓的合法数据库模式

7.5.1. 会有用户最近10年从未登录过，所以现在必填的一些字段对他们来说就是一堆空值

7.6. 总会存在一些当前的应用程序绝对无法生成的数据，这就是必须要针对真实生产数据的副本进行测试的原因

8. 无模式数据库

8.1. 对数据库引擎而言，无模式数据库仅仅无模式而已，但对应用程序来说，就完全是另一回事了

8.2. 随着时间的推移，应用程序很有可能也在不断演化，原来旧版本的数据文档现在可能都不可读了

8.2.1. 编写应用程序，使其能够读取任何时间创建的版本

8.2.1.1. 所有版本之间的转换都必须经过测试，这意味着需要保留旧文档作为测试的种子数据

8.2.1.2. 随着流水线越来越深，翻译时间会线性增加

8.2.2. 编写部署期间在整个数据库运行的迁移例程

8.2.2.1. 旧实例读取旧文档，没问题

8.2.2.2. 新实例读取旧文档，没问题

8.2.2.3. 新实例读取新文档，没问题

8.2.2.4. 旧实例读取新文档，会出大问题

8.2.3. 先滴流再批量

8.2.3.1. 这个策略不会对所有文档进行一次大规模的迁移

8.2.3.2. 通过在应用程序新版本中添加一些条件码，迁移运行过程中涉及的那些文档

8.2.3.3. 在生产环境实行了一段时间的“先滴流再批量”之后，就会发现最活跃的文档都已更新

8.2.3.4. 此时就可以对其余文档执行批量迁移，这可以与生产环境同时运行，不会产生危险，因为此时没有旧实例参与

8.2.3.5. 优点

8.2.3.5.1. 能实现快速部署新的应用程序版本，无须停机进行数据迁移

8.2.3.5.2. 能在不中断服务的情况下部署代码，因此当不再需要迁移测试时，能够将其删除

8.2.3.6. 缺点

8.2.3.6.1. 不能对相同的文档类型执行不同的重复滴流迁移操作

8.2.3.6.2. 当面对一些较大的设计变更时，需要将其分散到多个版本中来实现

8.2.3.7. 对于任何大型迁移——通常在部署过程中执行时间很长——都可以采用这种方法

9. 让人类定义规则，让机器贯彻规则

9.1. 实现自动化操作和质量检查

9.2. 运维工作与开发工作已经变得难解难分，这就要求必须按照可部署的原则设计软件，就像设计用于生产环境的软件一样

10. Web资源

10.1. 缓存破坏（cache-busting）

10.1.1. 能够帮助浏览器、所有中间代理和缓存服务器获取最新的静态资源

10.2. 版本控制

10.2.1. Git生成的SHA值作为版本标识符

10.3. 会话黏性

11. 推出新代码

11.1. “收敛”式基础设施

11.1.1. 这种基础设施使用长寿命的机器，并由这些机器接受变更

11.1.2. 决定每次要更新的机器数量

11.1.3. “金丝雀”组

11.1.4. 要阻止流量发往机器，一种简单的方法就是将其从负载均衡器池中移除

11.1.5. 通过健康状况检查，应用程序中一个简单的状态变更，就可以通知负载均衡器不再向该机器发送任何新请求，该机器正在处理的请求会继续完成

11.2. "不可变”的基础设施

11.2.1. 要针对新版本的代码启用新机器

11.2.2. 随着新机器不断出现且通过了健康状况检查，它们将开始承担流量负载，这意味着需要实现会话黏性，否则某个调用方后续发来的请求，就可能不得不交给新版本机器（而不是旧版本机器）来处理

11.3. 如果部署非常频繁，那么最好是在现有集群中启用新机器，这样做可以避免打断正在处理的连接

11.4. 在所有的模式下，机器上的内存会话数据都会发生丢失，必须让用户了解到这一点

12. 清理

12.1. 如果工具用完后没有归位，那么工作不能算完成

12.2. 去除垫片

12.2.1. 一旦每个实例都部署了新代码，就不再需要那些触发器了，那时就可以删除它们

12.2.2. 对于新的数据库迁移，务必最后要执行这样的删除操作

12.3. 收缩（contraction），或“收紧”数据库模式

12.3.1. 撤销旧表

12.3.2. 撤销旧视图

12.3.3. 撤销旧列

12.3.4. 撤销不再使用的别名和近义词

12.3.5. 撤销不再被调用的存储过程

12.3.6. 在新列上应用非空约束

12.3.7. 应用外键约束

12.4. 清理阶段也是审查特征切换的好时机

12.4.1. 任何新的特征切换都应默认设置为“关闭”