[译] 部署 != 发布 (第二部分)

• 原文地址：Deploy != Release (Part 2)
• 原文做者：Art Gillespie
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者： lwjcjmx123
• 校对者：LeviDing

将部署和发布解耦以下降风险，并解锁功能强大的工做流

在这系列的第一部分，我解释了咱们在 Turbine Labs 上用于上线、部署、发布和回滚的定义。我解释了部署风险和发布风险之间的差别。并且我还谈到了本地发布 —— 一种经常使用的用于将生产请求暴露给部署风险的部署/发布策略。本文中，我将讨论解耦部署风险与发布风险的方法，并简单介绍一些功能强大的工做流来管理发布风险。

蓝/绿部署（或部署!=发布）

蓝/绿部署涉及到在生产环境已有发布版本的同时部署新版本。你能够为每种“颜色”使用专用硬件或虚拟机，并在它们之间交替进行后续部署，也可使用容器或像 Kubernetes 这样的容器集群来管理临时进程。不管如何，关键在于一旦部署了新的（绿色）版本，它不会当即就被发布 —— 也不会响应生产请求。这些服务仍由目前运行良好的（蓝色）版本处理。

在蓝/绿部署体系中，发布一般会涉及到更改负载均衡，在添加新版本的主机以后，移除掉之前运行良好的旧版本。尽管这种方式要比本地部署好的多，它也会有一些局限性，尤为是在发布风险方面。回到正题。首先，咱们能够看到你能够作到不少很是强大的事情，经过不一样的步骤在部署和发布的时候

什么都没有

若是你的部署在循环崩溃回退中挂起，或这由于数据库密钥错误且新部署的服务没法链接，你也不用承受必需要作些什么事情来挽救的压力。你的团队能够在没有任何压力的状况下诊断问题或构建另外一个新版本，而后进行部署这个新版本。你能够很轻松的重复尝试，直到你部署的版本再也不出现问题。与此同时,线上的已发布 版本还在照常响应生产环境的请求,而且你没必要再公司博客上发布此次部署失败了的通知,换句话说,*你的部署风险基本都被掩盖了

健康检查和集成测试

当部署与发布被拆分时，你能够在任何生产环境流量暴露给它以前，针对新部署的版本运行自动化健康检查和集成测试。我参与过许多过后分析，其中最重要的一点是，在部署好后或者预发布的时候进行健康检查等简单的事情能够有效避免问题暴露在用户面前。

蓝/绿部署在健康检查和集成测试的时候。若是 v1.2 出现问题，客户将不会发现这些问题。

更细粒度的暴露发布风险

因为在引入新的“绿色”主机时，你不必定须要替换现有的“蓝色”主机，因此你能够有一些方法来控制新版本生成流量的百分比。例如，若是你有三台运行已知良好的服务版本，你能够在负载均衡器中再混入一台“绿色”主机。如今新版本只有 25% 的流量，而不是33%，只要你不是采用替换原有“蓝色”主机的状况下。虽然这仍然是至关粗放的版本风险管理，但总比没有好。

当你使一个“绿色”主机可用时，暴露该版本中任何错误流量的百分比则取决于主机的总数。这里是 33%。

持续发布

正如我以上的讨论，从部署风险角度看，蓝/绿部署更好。但当咱们考虑发布风险时，典型的蓝/绿设置处理版本的方式并不能为咱们提供咱们正在寻找的细粒度控制。若是咱们赞成生产中的每一个发布都是测试（无论赞成与否，它一直如此），而咱们真正想要的是使用模式匹配规则来分割咱们的生产请求，并动态分配任意百分比的流量到咱们服务的任何版本。这是一个强大的概念，它是构成复杂发布工做流的基础，如内部测试、增量发布、版本回退和黑暗流量。每篇文章都分为上下两部分（即将推出！），但我在这里会大概的介绍一下他们。

内部测试是仅向员工发布新版本服务的流行技术。经过强大的发布服务，你能够编写诸如“将内部员工流量的 50% 发送到版本为 x.x 实例”的规则。在个人职业生涯中，生产中的内部测试捕获到了许多我羞于认可的使人尴尬的错误。

增量发布是一个过程，从发送一些小百分比生产请求到新版本服务开始，同时监视这些请求的性能 —— 错误、延迟、成功率等 —— 与以前的产品版本相比而言。当你确信新版本不会出现任何相对上一版本意外行为的时候，你能够增长百分比并重复此过程，直至到达 100%。

回滚是在使用持续性发布系统的时候，将生产中的请求转发到最后一个运行良好的实例。它速度快、风险低，而且像发布自己同样，能够经过细粒度方式有针对地完成。

黑暗流量是一种功能强大的技术。你发布的系统会复制生产请求，并将一个副本发送到你的服务运行良好的“明面”上的版本，另外一个发送到新的“暗处”的版本。暴露在“明面”的版本负责实际响应用户请求。“暗处”的版本也会处理请求，但其响应会被忽略。当您须要在生产环境下测试新软件时，这很是有效。

在 Turbine Labs 中，咱们使用本身的产品 Houston 来完成内部测试，增量发布、回滚，并很快进行黑暗流量。对我来讲，像 Houston 这样先进的发布系统对个人平常工做来讲是一种革命性改变。如此轻量级、低风险的发布，使得我能够常常这样作。做为一个团队，它以我没有预料到的方式提升了咱们的功能发布速度和产品质量。咱们将在之后的文章中更详细地介绍咱们在 Turbine Labs 的内部发布流程。

结论

在过去的五年中，软件发布领域的大部分技术和流程进展 —— 云计算、容器、编排框架、持续交付等 —— 都集中在部署上。有了这些进步，为你的服务设计和实现一个健壮的部署流程变得垂手可得，但设计和实现一个能够支持你服务需求的可靠发布流程仍然十分困难。Facebook、Twitter 和 Google 致力于设计、实现和持续维护像 Gatekeeper、TFE 和 GFE 这样成熟的发布系统。这些系统不只在服务可靠性方面屡次证实了它们的价值，还包括开发者生产、产品速度和用户体验方面。

一个先进的发布系统不只能够下降部署风险，还能够直接提升产品速度和用户体验。

咱们开始关注为各类规模的公司提供的便利的产品（Houston、LaunchDarkly）和开源工具（Envoy、Linkerd、Traefik、Istio），以及最近才向大型公司提供的发布单元和工做流。这些产品和工具使得人们能够更快速地发布功能，而且使咱们有信心不会对用户体验产生负面影响。

我是 Turbine Labs 的一名工程师，咱们正在构建 Houston —— 一项使构建和监控复杂的实时发布工做流程变得很是简单的服务。若是你但愿交付更多产品而且花更少的心思，那么你绝对应该联系咱们！咱们很乐意与你交流。

感谢 Glen Sanford、Mark McBride、Emily Pinkerton、Brook Shelley、Sara 和 Jenn Gillespie 阅读本文的初稿并提出修改意见。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。