1. 部署环节

1.1. 部署软件是指将软件包送到它们需要运行的地方的行为

1.2. 移动应用的部署与核反应堆的部署不同，但同样的基本原则都适用

1.3. 自动部署

1.3.1. 使用脚本而不是手动步骤来部署软件

1.3.2. 自动部署的可预测性更高，因为脚本的行为是可以重复的，并且有版本控制

1.3.3. 当事情出错时，运维人员能够推理出部署行为

1.3.4. 脚本比人更不容易犯错，而且它们消除了在部署过程中去手动调整系统、登录计算机或复制软件包的诱惑

1.3.5. 高度发展的自动化催生了持续交付

1.3.5.1. 通过持续交付，人力被完全从部署环节中移除

1.3.5.2. 打包、测试、发布、部署，甚至展开环节都是自动化的

1.3.6. 建议用现成的工具来自动化你的部署操作

1.3.6.1. Puppet、Salt、Ansible和Terraform等现成的解决方案可以与现有的工具集成，并且它们是专门为了自动化部署而设计的

1.3.7. 只需尽力通过自动化周围的一切来缩小阻断任务的边界

1.4. 部署的原子性

1.4.1. 安装脚本通常涉及多个步骤，不要假设每一步都能成功执行

1.4.2. 应使部署要么全部完成要么什么都没做（即原子性）

1.4.3. 使部署原子化的最简单方法之一是在与旧版本不同的位置上安装软件，不要覆盖任何东西

1.4.4. 在新的位置安装软件包还有一个好处，那就是回滚将变得更加容易

1.4.4.1. 只需再次指向旧的版本

1.4.5. 同一软件的不同版本可以在同一台计算机上同时运行

1.5. 独立地部署应用

1.5.1. 顺序部署

1.5.1.1. 一个应用程序的部署需要先升级另一个应用程序

1.5.1.2. 这是在有许多应用程序或服务相互通信的软件中常见的问题

1.5.1.3. 顺序部署的需求会减慢部署速度，因为应用程序必须相互等待

1.5.2. 务必避免顺序部署的需求

1.5.3. 构建可独立部署的应用程序

1.5.3.1. 不依赖顺序部署的软件必须向后和向前兼容

1.5.3.2. 通信协议必须继续允许较新和较旧的版本相互操作

2. 展开环节

2.1. 一旦新的代码被部署了，你就可以解开它（也就是展开）

2.2. 一下子把所有东西都换成新的代码是有风险的

2.2.1. 再多的测试都不会消除潜在的错误，而且一次性向所有的用户展开代码会同时对每个人造成损害

2.3. 特性开关、金丝雀部署和蓝绿部署都只面向一部分用户展开代码，并在出现问题时提供缓解机制

2.4. 系统监控

2.4.1. 增加或减少的决定仍然是由人们参考日志和系统指标而做出的

2.4.2. 当代码被提交时，你的工作还没有完成

2.4.3. 当代码被展开时，它仍然没有完成

2.5. 特性开关

2.5.1. feature flag

2.5.2. 特性切换或代码分割

2.5.3. 允许开发人员控制新代码何时发布给用户

2.5.4. 可以是“开”和“关”的布尔型的值、允许列表、基于百分比的斜坡，甚至是小型函数

2.5.5. 基于百分比的斜坡允许开发者为更大范围的用户慢慢打开该特性，通常从公司拥有的测试账户开始，然后在进行基于百分比的增量发布之前，先向单个用户倾斜

2.5.6. 函数根据输入的数动态地确定开关，通常在用户请求时就传入

2.5.7. 如果可能的话，隔离与特性开关相关联的数据，在所有的开关状态下测试你的代码，并编写脚本来清理回滚的特性数据

2.5.8. 请确保清理那些已经被完全淘汰或不再使用的旧特性开关

2.5.9. 清理特性开关就像重构一样，应该渐进地、适时地进行清理

2.5.10. 大多数的特性开关是由人类控制的

2.5.11. 特性开关有时被用于A/B测试，这是一种测试用户对新特性反应的技术

2.5.11.1. 如果以具有统计意义的方式对用户进行分组，用特性开关进行A/B测试是可行的

2.5.11.2. 除非开关分发系统为你创建水桶测试用到的桶，并由数据科学家运行你的实验，否则不要尝试用特性开关进行A/B测试

2.6. 熔断器

2.6.1. 是二进制的（开/关）、永久性的，而且是自动化的

2.6.2. 熔断器是一种特殊的特性开关，由运维事件（如延迟的峰值或异常）控制

2.6.3. 熔断器用来防止性能下降

2.6.3.1. 如果超过了延迟的阈值，某些特性可以被自动禁用或限制速率

2.6.3.2. 如果日志显示出异常行为——程序异常或日志详细程度的飙升，也可以触发熔断

2.6.3.3. 熔断器还可以防止永久性损坏

2.7. 并行的服务版本梯队

2.7.1. 将新版本的网络服务与旧版本一起部署是具有可行性的

2.7.2. 平行部署可以让你缓慢地升级，以降低风险，并在出错时快速回滚

2.7.3. 两个版本的应用程序都必须能很好地相互配合

2.7.4. 所有模式都必须贯彻向后和向前兼容

2.7.5. 金丝雀部署和蓝绿部署是两种非常常见的并行部署策略

2.7.6. 金丝雀部署用于处理高流量并会部署到大量实例的服务

2.7.6.1. 一个新的应用程序版本被首先部署到一组受限的计算机上，全部用户中的一个小的子集会被路由到这个金丝雀版本

2.7.7. 蓝绿部署指的是运行两个不同版本的应用程序：一个是主动的，一个是被动的

2.7.7.1. 新版本被部署到被动环境中，当它准备好时，流量被切换到新版本，它就变成了主动的，而以前的版本则变成了被动的

2.7.7.2. 与金丝雀部署不同的是，流量的切换是原子化的，蓝色和绿色环境尽可能地保持一致

2.7.7.3. 在云环境中，一旦版本被认为是稳定的，被动环境通常会被销毁

2.7.7.4. 当流量不容易被划出子集或者无法并行运行不同的版本时，蓝绿部署就派上了用场

2.7.7.5. 与金丝雀部署不同的是，每个环境必须能够处理100%的用户流量

2.8. 摸黑启动

2.8.1. 摸黑启动（有时被称为影子流量）将新的代码暴露在真实的流量中，而不使其对终端用户可见，即使代码是坏的，也没有用户受到影响

2.8.2. 摸黑启动的软件其实仍然启用了，代码也被调用了，只是结果被丢掉了

2.8.3. 摸黑启动可帮助开发者和运维人员在生产环境中了解他们的软件，对用户的影响最小

2.8.4. 每当你发布特别复杂的变化时，就可以利用摸黑启动的优势

2.8.5. 这种模式对于验证系统的迁移特别有效

2.8.6. 在摸黑启动模式下，应用程序的代理位于实时流量和应用程序之间

2.8.7. 某个系统在暗中读取模式下运行时，可能使用与生产系统相同的数据存储

2.8.8. 由于同一请求有两次操作，一次在生产系统，一次在影子系统，你应该注意避免与重复相关的错误

526互联

读程序员的README笔记11_软件交付（下）

1. 部署环节

1.1. 部署软件是指将软件包送到它们需要运行的地方的行为

1.2. 移动应用的部署与核反应堆的部署不同，但同样的基本原则都适用

1.3. 自动部署

1.3.1. 使用脚本而不是手动步骤来部署软件

1.3.2. 自动部署的可预测性更高，因为脚本的行为是可以重复的，并且有版本控制

1.3.3. 当事情出错时，运维人员能够推理出部署行为

1.3.4. 脚本比人更不容易犯错，而且它们消除了在部署过程中去手动调整系统、登录计算机或复制软件包的诱惑

1.3.5. 高度发展的自动化催生了持续交付

1.3.5.1. 通过持续交付，人力被完全从部署环节中移除

1.3.5.2. 打包、测试、发布、部署，甚至展开环节都是自动化的

1.3.6. 建议用现成的工具来自动化你的部署操作

1.3.6.1. Puppet、Salt、Ansible和Terraform等现成的解决方案可以与现有的工具集成，并且它们是专门为了自动化部署而设计的

1.3.7. 只需尽力通过自动化周围的一切来缩小阻断任务的边界

1.4. 部署的原子性

1.4.1. 安装脚本通常涉及多个步骤，不要假设每一步都能成功执行

1.4.2. 应使部署要么全部完成要么什么都没做（即原子性）

1.4.3. 使部署原子化的最简单方法之一是在与旧版本不同的位置上安装软件，不要覆盖任何东西

1.4.4. 在新的位置安装软件包还有一个好处，那就是回滚将变得更加容易

1.4.4.1. 只需再次指向旧的版本

1.4.5. 同一软件的不同版本可以在同一台计算机上同时运行

1.5. 独立地部署应用

1.5.1. 顺序部署

1.5.1.1. 一个应用程序的部署需要先升级另一个应用程序

1.5.1.2. 这是在有许多应用程序或服务相互通信的软件中常见的问题

1.5.1.3. 顺序部署的需求会减慢部署速度，因为应用程序必须相互等待

1.5.2. 务必避免顺序部署的需求

1.5.3. 构建可独立部署的应用程序

1.5.3.1. 不依赖顺序部署的软件必须向后和向前兼容

1.5.3.2. 通信协议必须继续允许较新和较旧的版本相互操作

2. 展开环节

2.1. 一旦新的代码被部署了，你就可以解开它（也就是展开）

2.2. 一下子把所有东西都换成新的代码是有风险的

2.2.1. 再多的测试都不会消除潜在的错误，而且一次性向所有的用户展开代码会同时对每个人造成损害

2.3. 特性开关、金丝雀部署和蓝绿部署都只面向一部分用户展开代码，并在出现问题时提供缓解机制

2.4. 系统监控

2.4.1. 增加或减少的决定仍然是由人们参考日志和系统指标而做出的

2.4.2. 当代码被提交时，你的工作还没有完成

2.4.3. 当代码被展开时，它仍然没有完成

2.5. 特性开关

2.5.1. feature flag

2.5.2. 特性切换或代码分割

2.5.3. 允许开发人员控制新代码何时发布给用户

2.5.4. 可以是“开”和“关”的布尔型的值、允许列表、基于百分比的斜坡，甚至是小型函数

2.5.5. 基于百分比的斜坡允许开发者为更大范围的用户慢慢打开该特性，通常从公司拥有的测试账户开始，然后在进行基于百分比的增量发布之前，先向单个用户倾斜

2.5.6. 函数根据输入的数动态地确定开关，通常在用户请求时就传入

2.5.7. 如果可能的话，隔离与特性开关相关联的数据，在所有的开关状态下测试你的代码，并编写脚本来清理回滚的特性数据

2.5.8. 请确保清理那些已经被完全淘汰或不再使用的旧特性开关

2.5.9. 清理特性开关就像重构一样，应该渐进地、适时地进行清理

2.5.10. 大多数的特性开关是由人类控制的

2.5.11. 特性开关有时被用于A/B测试，这是一种测试用户对新特性反应的技术

2.5.11.1. 如果以具有统计意义的方式对用户进行分组，用特性开关进行A/B测试是可行的

2.5.11.2. 除非开关分发系统为你创建水桶测试用到的桶，并由数据科学家运行你的实验，否则不要尝试用特性开关进行A/B测试

2.6. 熔断器

2.6.1. 是二进制的（开/关）、永久性的，而且是自动化的

2.6.2. 熔断器是一种特殊的特性开关，由运维事件（如延迟的峰值或异常）控制

2.6.3. 熔断器用来防止性能下降

2.6.3.1. 如果超过了延迟的阈值，某些特性可以被自动禁用或限制速率

2.6.3.2. 如果日志显示出异常行为——程序异常或日志详细程度的飙升，也可以触发熔断

2.6.3.3. 熔断器还可以防止永久性损坏

2.7. 并行的服务版本梯队

2.7.1. 将新版本的网络服务与旧版本一起部署是具有可行性的

2.7.2. 平行部署可以让你缓慢地升级，以降低风险，并在出错时快速回滚

2.7.3. 两个版本的应用程序都必须能很好地相互配合

2.7.4. 所有模式都必须贯彻向后和向前兼容

2.7.5. 金丝雀部署和蓝绿部署是两种非常常见的并行部署策略

2.7.6. 金丝雀部署用于处理高流量并会部署到大量实例的服务

2.7.6.1. 一个新的应用程序版本被首先部署到一组受限的计算机上，全部用户中的一个小的子集会被路由到这个金丝雀版本

2.7.7. 蓝绿部署指的是运行两个不同版本的应用程序：一个是主动的，一个是被动的

2.7.7.1. 新版本被部署到被动环境中，当它准备好时，流量被切换到新版本，它就变成了主动的，而以前的版本则变成了被动的

2.7.7.2. 与金丝雀部署不同的是，流量的切换是原子化的，蓝色和绿色环境尽可能地保持一致

2.7.7.3. 在云环境中，一旦版本被认为是稳定的，被动环境通常会被销毁

2.7.7.4. 当流量不容易被划出子集或者无法并行运行不同的版本时，蓝绿部署就派上了用场

2.7.7.5. 与金丝雀部署不同的是，每个环境必须能够处理100%的用户流量

2.8. 摸黑启动

2.8.1. 摸黑启动（有时被称为影子流量）将新的代码暴露在真实的流量中，而不使其对终端用户可见，即使代码是坏的，也没有用户受到影响

2.8.2. 摸黑启动的软件其实仍然启用了，代码也被调用了，只是结果被丢掉了

2.8.3. 摸黑启动可帮助开发者和运维人员在生产环境中了解他们的软件，对用户的影响最小