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的GoCD4.1.2.3. Netflix公司的Spinnaker4.1.2.4. 亚马逊的AWS Code Pipeline4.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. 任何新的特征切换都应默认设置为“关闭”