Deploy != Release（第一部分）：部署与发布的区别，以及为什么这很重要

Apr 19, 2018

翻译自：Deploy != Release (Part 1): The difference between deploy and release and why it matters.

问：「最新版本部署了吗？」

答：「我在生产环境里部署了 gif 动图支持。」

问：「就是说 gif 动图支持已经发布啦？」

答：「Gif 动图的发布版本已经部署了。」

问：「……」

我曾在很多公司工作过，在这些公司中「部署（deploy，动词）」、「部署物（deployment，名词）」、「上线（ship）」和「发布（release）」都是随意地使用，甚至可以互换使用。作为一个行业，我们在规范使用这些术语方面做得还不够，尽管我们在过去的十多年里已经从根本上改进了运维实践和工具。在 Turbine Labs 中，我们使用了「上线」、「部署」、「发布」和「回滚（rollback）」的精确定义，并花了大量的时间来思考当你把「发布」作为上线过程的一个独立阶段时，世界是什么样子的。在这篇文章的第一部分，我会分享这些术语的定义，描述一些常见的「部署 == 发布」的实践，并且解释为什么这样做的抗风险性很差。在第二部分，我会描述当「部署」和「发布」被视为软件上线周期的不同阶段时的一些非常强大的风险缓释技术。

上线

上线指你的团队从源码管理库中获取服务代码某个版本的快照，并用它处理线上流量的过程。我认为整个上线过程由四个不同的专门的小流程组成：构建（build）、测试、部署和发布。得益于云基础架构、容器、编配框架的技术进步以及流程改进，如 twelve-factor、持续集成和持续交付，执行前三个流程（构建，测试和部署）从未如此简单。

部署

部署指你的团队在生产环境的基础设置中安装新版本服务代码的过程。当我们说新版软件被部署时，我们的意思是它正在生产环境的基础设施的某个地方运行。基础设置可以是 AWS 上的一个新启动的 EC2 实例，也可以是在数据中心的 Kubernetes 集群中的某个容器中运行的一个 Docker 容器。你软件已成功启动，通过了健康检查，并且已准备好（像你希望的那样！）来处理线上流量，但实际上可能没有收到任何流量。这是一个重要的观点，所以我会用 Medium 超棒的大引用格式来重复一遍：

部署不需要向用户提供新版本的服务。

根据这个定义，部署可以是几乎零风险的活动。诚然，在部署过程中可能会出现很多问题，但是如果一个容器静默应对崩溃，并且没有用户获得 500 状态响应，那问题是否真的算是发生了？

部署了新的版本（紫色），但未发布。已知良好的版本（绿色）仍对线上请求做出响应。

发布

当我们说服务版本发布时，我们的意思是它负责服务线上流量。在动词形式中，发布是将线上流量转移到新版本的过程。鉴于这个定义，与上线新的二进制文件有关的所有风险 —— 服务中断、愤怒的用户、The Register 中的刻薄内容 —— 与新软件的发布而不是部署有关。在一些公司，我听说这个上线阶段被称为首次发布（rollout）。这篇文章中我们将依旧使用发布来表述。

新版本发布，响应线上请求。

回滚

迟早，很可能不久之后，你的团队就会上线一些功能有问题的服务。回滚（和它危险的、不可预测的、压力山大的兄弟 —— 前滚 roll-forward）指将线上服务退回到某个已知状态的过程，通常是重新发布最近的版本。将回滚视为另一个部署和发布流程有助于理解，唯一的区别是：

你正在上线的版本的特征在生产环境中已知
你正在时间压力下执行部署和发布过程
你可能正向一个不同的环境中发布 —— 在上次失败的发布之后某些东西可能改变了（或被改变了）

一个发布后回滚的例子。

现在我们已经就上线、部署、发布和回滚的定义达成了共识，让我们来看看一些常见的部署和发布实践。

原地发布（即部署 == 发布）

当你的团队的上线流程涉及将新版本的软件推送到运行旧版本的服务器上并重启服务的流程时，你就是在原地发布。根据我们上面的定义，部署和发布是同时发生的：一旦新软件开始运行（部署），它就会负载旧版本的所有线上流量（发布）。此时，成功的部署就是成功的发布，失败的部署则会带来部分或整体的服务中断，一群愤怒的用户，可能还有一个气急败坏的经理。

在我们所讨论的部署/发布过程中，原地发布是唯一的将部署风险暴露给用户的方式。如果你刚刚部署的新版本无法启动 —— 可能是因为无法找到新增的环境变量而抛出异常，也可能是有一个库依赖不满足，或者只是你今天出门时没看黄历 —— 此时并没有老版本的服务实例来负载用户请求。你的服务此时至少是部分不可用的。

此外，如果有用户相关的问题或更微妙的运维问题 —— 我把它叫做发布风险 —— 原地发布会将线上请求暴露给你已发布的所有实例。

在集群环境中，您可能会首先原地发布一个实例。这种做法通常称为金丝雀发布，它可以减轻一些风险 —— 面临部署风险和发布风险的流量的百分比为：新服务实例的个数除以集群中的实例总数。

一个金丝雀发布：集群中的一个主机运行新版本

最后，回滚错误的原地部署可能会有问题。即使你回滚（重新发布）到旧版本，也无法保证可以恢复到以前的系统状态。与当前错误的部署一样，你的回滚部署在启动时也可能会失败。

尽管其风险管理相对较差 —— 即便使用金丝雀，一些用户请求也会面临部署风险 —— 原地部署仍旧是业务中常见的方式。我认为这类的经验会导致不幸地混用「部署」和「发布」这两个术语。

别绝望

我们可以做得更好！在这篇文章的第二部分，我们会讨论分离部署和发布的策略，以及可以在复杂的发布系统上构建的一些强大工作流。

我是 Turbine Labs 的一名工程师，我们正在构建 Houston，这个服务可以轻松构建和监控复杂的实时发布工作流程。如果你想轻松地上线更多服务，你绝对应该联系我们。我们很乐意与你交谈。

感谢 Glen Sanford、Mark McBride、Emily Pinkerton、Brook Shelley、Sara 和 Jenn Gillespie 阅读此文的草稿。

感谢 Glen D Sanford。

转载于:https://my.oschina.net/newlife111/blog/1841228