在现实应用中，开发者会频繁地部署服务，并需要能够在不停机的情况下部署新版本服务来保持应用的整体稳定性。因为每个服务的正常运行依赖于其他服务，所以还需要最大限度地提高每个服务的可用性。

不停机部署有3种常见的部署模式。

（1）滚动部署：在启动新实例（版本为N+1）时，逐步将旧实例（版本为N）从服务中剔除，确保在部署期间最小比例的负载容量得到保证。

（2）金丝雀部署：开发者在服务中添加一个新实例来验证N+1版本的可靠性，然后再全面推出。这种模式在常规滚动部署之外提供了附加安全措施。

不停机部署服务3种常见模式_开发者

向实例组中添加一个金丝雀实例，后端服务开始接受请求。

如果没有问题的话，可以继续执行滚动更新，更新速度取决于在滚动更新时期望保留多大的服务能力。

如果不满意的话，可以将金丝雀实例回滚。回滚命令和滚动部署命令是相同的，不过它用的是之前的版本。在现实世界中，回滚可能并不是原子化的。比如，对新实例执行错误操作可能会导致数据处于不一致的状态，这就需要人为干预和协调。发布小规模的变更并积极监控新发布版本的功能能够降低这些情况的发生和范围。

（3）蓝绿部署：创建一个运行新版本代码的并行服务组（绿色集合），开发者逐步将请求从旧版本（蓝色集合）中转移出去。在服务消费者对错误率高度敏感、无法接受不健康的金丝雀风险的情况下，这种方法比金丝雀部署模式更有效。

所有这些模式都是基于简单的操作构建的。开发者获取一个实例，在环境中运行该实例，并将流量导向该实例。

认为第一次自动化测试失败的问题，主要出在缺乏规划和设计上。既然找到了问题，我决定和我的小伙伴一起，再来做一次自动化。

既然是要做规划，第一步肯定是定目标。由于团队也是第一次做自动化，那从简单内容入手是比较靠谱的；另外回归测试中有大量重复测试工作，测试的内容也比较基础，很适合使用自动化。这样我们团队的自动化目标就变成了从简单的内容开始，将自动化脚本用于回归测试，达到100%自动化回归测试。

这个目标看起来没毛病，但实际执行起来却变了味。在“简单的内容先自动化”的思想下，大家心照不宣地做了很多非常简单的测试界面配置的边界值脚本。

由于希望把自动化脚本用于回归测试，这些测试配置的极简脚本就顺理成章地成为回归测试用例集。

但这样的回归测试自动化，大家打心底都不认同，觉得这些脚本的测试内容执行起来没有任何意义，就是说出去好听而已（我们实现了100%回归自动化测试）。运行几次之后，大家就很自然地不想再继续了。

这次经历让我对自动化测试有了新的思考——自动化测试要从解决烦琐工作入手，而不是从简单工作入手，要让团队看到自动化测试切实的效果。只有这样，自动化才能真正被团队接受，而不是变成劳民伤财的花架子。