生产环境部署不仅仅是发布新代码。

它还包括验证、监控，以及出错时的恢复计划。

在这里，@manishmshiva 带你逐步了解一次真实部署的各个阶段，包括构建、产物、迁移和回滚。

https://freecodecamp.org/news/what-happens-during-a-production-deployment/…

生产环境部署期间会发生什么？一份幕后指南

来源：https://www.freecodecamp.org/news/what-happens-during-a-production-deployment/ 生产环境部署期间会发生什么？一份幕后指南你推送代码。几分钟后，它就面向真实用户上线了。

在这两个时刻之间，运行着一条长长的机械链：构建、产物、迁移、健康检查、流量切换。每一位生产环境工程师都依赖这条链，而许多团队仍在自行构建和运维它。

部署基础设施已在不知不觉中变成了运维开销。它最初是一种技术必需品，是每个团队都必须自己组装的东西，因为没有其他现成方案。

如今，它成了你的工程师在产品之外维护的第二个系统，消耗着值班轮换、迭代容量，以及本可以用在更重要地方的凌晨两点的注意力。

在这篇文章中，我们将逐步了解一次真实生产环境部署的各个阶段：构建、它产生的产物、数据库迁移、健康检查、滚动更新和回滚。在此过程中，我们将看看为什么平台即服务（PaaS）(https://www.freecodecamp.org/news/my-team-s-experience-moving-from-aws-to-a-paas/)工具会替你处理其中大部分步骤，以及团队继续自行处理这些步骤需要付出什么代价。

目录

• 构建：将代码变成可运行的东西 (https://www.freecodecamp.org/news/what-happens-during-a-production-deployment/#heading-the-build-turning-code-into-something-that-can-run)
• 产物：一个版本，冻结在时间中 (https://www.freecodecamp.org/news/what-happens-during-a-production-deployment/#heading-the-artefact-one-version-frozen-in-time)
• 数据库迁移：风险最高的一步 (https://www.freecodecamp.org/news/what-happens-during-a-production-deployment/#heading-database-migrations-the-riskiest-step)
• 健康检查：证明新版本还活着 (https://www.freecodecamp.org/news/what-happens-during-a-production-deployment/#heading-health-checks-proving-the-new-version-is-alive)
• 滚动更新：在飞行中更换飞机引擎 (https://www.freecodecamp.org/news/what-happens-during-a-production-deployment/#heading-rolling-updates-replacing-the-planes-engine-mid-flight)
• 回滚：逃生舱 (https://www.freecodecamp.org/news/what-happens-during-a-production-deployment/#heading-rollbacks-the-escape-hatch)
• 什么时候你不需要 PaaS (https://www.freecodecamp.org/news/what-happens-during-a-production-deployment/#heading-when-you-dont-need-a-paas)
• 你还应该自己运行这套系统吗？ (https://www.freecodecamp.org/news/what-happens-during-a-production-deployment/#heading-should-you-still-be-running-this-yourself)

构建：将代码变成可运行的东西

部署并不会按原样发布你的源代码。它发布的是构建的结果。构建阶段会将你的代码变成服务器可以运行的东西。

具体形式取决于你的技术栈。Java 或 Go 项目会被编译成二进制文件。JavaScript 前端会被打包和压缩。Python 应用会解析并锁定依赖。在大多数现代设置中，所有这些都会被打包成一个容器镜像 (https://www.freecodecamp.org/news/an-introduction-to-docker-and-containers-for-beginners/)，也就是你的应用及其运行所需一切资源的冻结快照。

构建阶段还会运行你的测试。单元测试、代码检查和安全扫描都在这里进行。如果其中任何一项失败，部署就会在触及生产环境之前停止。这是捕获 bug 成本最低的地方。一次失败的构建只会浪费你几分钟。一次失败的部署可能会让你失去客户。

代码部署的各个阶段自行管理管道的团队会在这里投入大量精力。他们需要维护构建服务器、缓存依赖、调试不稳定的测试运行器。

这些工作没有一项是为了交付功能。它们是纯粹的维护工作，而且永远不会结束。PaaS 会把整个阶段内置到平台中。你推送代码，平台检测你的语言，以同样的方式每次都构建它，并在出错时快速失败。构建仍然会发生。只是你的工程师不再需要用数小时的时间为它买单。

产物：一个版本，冻结在时间中

构建的输出称为产物。它可以是容器镜像、编译后的二进制文件或压缩包。无论格式如何，产物只有一个任务：确保精确。它代表了应用的一个精确版本，在某个时间点上被冻结。

这比听起来更重要。通过测试的产物必须与到达生产环境的产物完全相同。如果你在测试和发布之间重新构建，就会有发布出略有不同内容的风险。依赖可能已经更新。构建标志可能已经改变。“它在预发布环境没问题”通常意味着“我们构建了两次，得到了两个不同的结果”。

良好的流水线只构建一次，并在每个阶段推广同一个产物。产物会被版本化并存储在注册表中，因此任何版本都可以在之后被拉取并重新运行。存储的历史记录也正是使回滚成为可能的原因，我们稍后会谈到。

在 PaaS 上，产物处理默认就是标准实践。每次部署都会产生一个带编号的版本。平台会存储它、跟踪它，并能恢复它。你不必设计注册表策略、编写推广脚本，或指派一名工程师来维护它们。这种纪律已经内置了。

数据库迁移：风险最高的一步

在新代码上线之前，数据库通常也需要随之改变。也许新版本需要新列或新表。这些更改称为迁移，它们是大多数部署中最危险的部分。

为什么？代码很容易替换。数据则不然。如果你部署了一个有问题的代码版本，你可以把它换掉。如果迁移损坏或删除了数据，可能就没有干净的回退路径了。迁移还会造成一个棘手的窗口期。在几分钟内，旧代码和新代码可能同时对着同一个数据库运行。在这个窗口期内，两个版本都必须能配合新的数据库模式工作。

安全的模式是让迁移向后兼容。先添加新列，部署能同时处理两种形态的代码，然后在后续版本中清理旧列。这需要更多步骤，但每一步本身都是安全的。

PaaS 不能替你编写迁移。没有工具能知道你数据的含义。但一个好的平台会给迁移在发布流程中一个明确的位置，按顺序运行它们，并准确记录什么在什么时候运行过。这种结构能防止那种经典故障：有人手动运行了迁移，却忘了告诉团队。

健康检查：证明新版本还活着

一旦新版本启动，平台并不会直接信任它。它会检查。健康检查是应用中的一个小端点，通常只是一个返回 “OK” 的路由。平台会反复调用它。如果应用有响应，就被认为是健康的。如果没有，平台就会认为出了问题。

通常有两种检查。就绪检查（readiness check）会问：“你准备好接收流量了吗？”存活检查（liveness check）则会问：“你还在正常工作吗，还是应该重启你？”这个区别很重要。一个应用可能是活的，但还没准备好，比如它仍在预热缓存时。

健康检查是部署的守门人。在新版本证明自己能处理请求之前，不会有流量到达它那里。没有健康检查，你就会把真实用户路由到一个可能仍在启动时崩溃的应用。

每一个严肃的 PaaS 都会自动运行健康检查。你定义端点，平台处理轮询、超时和决策。自己构建这些的团队需要手动调优所有这些设置，而且他们通常要通过痛苦的试错才能学会正确的数值。这笔学费是以工程时间支付的，而这个问题行业多年前就已经解决了。

滚动更新：在飞行中更换飞机引擎

这是难点所在。你的旧版本此刻正在服务线上流量。你需要在不丢失任何一个请求的情况下替换它。最常见的答案是滚动更新 (https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/)。

它的工作方式是这样的。假设你有四个应用实例在运行。平台启动一个新版本实例，等待其健康检查通过。然后将一小部分流量切换给它，并关闭一个旧实例。它重复这个过程，一次一个实例，直到只剩下新版本。用户完全不会注意到，因为在每个时刻都有足够多的健康实例来服务所有人。

一些团队使用这种思路的变体。蓝绿部署（blue-green deployment）在新版本旁边运行完整的新版本，然后一次性切换所有流量。金丝雀发布（canary release）先将一小部分用户流量发送到新版本，在扩大范围之前观察错误。

手动执行这些意味着要编写编排逻辑、管理负载均衡器规则，并处理每一步中途失败的所有边缘情况。这需要数月的工程努力来构建，并且需要永久的维护成本，而所有这些行为都是 PaaS 默认就具备的。在平台上，你可以开箱即用地获得零停机发布，而不是一个需要你团队投入人力的项目。

回滚：逃生舱

有时候，新版本通过了所有检查，但仍然破坏了某些真实的东西。错误率攀升。页面空白加载。这时速度比什么都重要，而最快的修复方式通常不是新补丁，而是回滚：重新部署你已知可用的上一个产物。

这就是冻结、带版本的产物如此重要的原因。只有当旧版本被存储、测试并随时可以运行时，回滚才能快速完成。在压力下从旧提交重建的团队，是在最糟糕的时机赌博。

在大多数 PaaS 平台上，回滚只是一个命令或一次点击。平台会保留你的发布历史，并能在一秒内恢复任何之前的版本。这一功能比任何其他功能都更能拯救值班工程师的夜晚。

什么时候你不需要 PaaS

把部署交给平台的理由很充分，但这并不适用于所有人。有些团队拥有自己的流水线并不是负担，而是一个深思熟虑且合理的工程决策。

当合规性要求如此

金融、医疗、政府等受监管行业，通常要在标准 PaaS 无法开箱即用地满足的要求下运营。数据驻留规则可能会规定你的构建具体接触到哪些物理基础设施。审计要求可能需要一定程度的数据溯源和访问日志，而托管平台不一定能提供。

安全控制可能需要扩展到构建环境本身，而不仅仅是运行时。在这些情况下，拥有流水线的成本是实实在在的，但这是在该行业运营所需的成本。

当部署本身就是你的产品

如果你的公司销售部署基础设施、CI/CD 平台、发布编排工具、内部开发者平台，那么你的流水线根本就不是开销。它就是产品。

维护它的工程师做的是产品工作，而不是杂务。大型组织中的平台工程团队也是如此，他们的明确职责就是为其他数十个内部团队构建和拥有部署层。在这两种情况下，“我们为什么要自己运行这套系统”这个问题都有显而易见的答案：因为这就是我们所做的事。

当你的基础设施确实不寻常

大多数 PaaS 平台都是为无状态 Web 服务和标准容器工作负载而优化的。如果你的系统超出这个范围，比如 GPU 集群、有严格延迟要求的实时系统、本地和云端混合部署、硬件在环测试，通用平台可能根本不适用。

将不寻常的工作负载硬塞进 PaaS，往往比围绕你实际面对的具体约束构建狭窄、专门用途的部署工具产生更多摩擦。

这三种情况之间的共同主线是特殊性。那些应该拥有自己流水线的团队，通常能清楚说明为什么平台不适合。如果答案是“我们一直这么做”或“我们喜欢控制感”，那值得质疑。如果答案是“我们的合规要求规定必须使用 X”或“我们卖这个”，那这是一个理由。

你还应该自己运行这套系统吗？

PaaS 并不会让这些步骤消失。构建仍然会运行。产物仍然会被存储。迁移仍然会执行，健康检查仍然会轮询，流量仍然会一个个实例地切换。抽象化这些机制并不会消除它们。它会将它们标准化，并把它们的维护工作交给一个整个产品就是部署的团队。

这才是每个产品团队现在都应该直面的问题：为什么我们还要自己构建和运维这套机制？十年前，自定义流水线是不可避免的。今天，这是一个选择，而且对大多数团队来说，这是一个错误的选择。每花一小时调试不稳定的构建代理、调优健康检查超时、或修补编排脚本，都是从客户真正付费的产品上拿走的一小时。流水线不会让你与众不同。它不能。你竞争对手的部署方式和你的一样。

要理解这条链是如何工作的，因为凌晨两点的值班工作有此要求。但知道它如何工作，并不是拥有它的理由。“我们自己构建了部署系统”不再是一枚荣誉勋章。它是在承认你的团队维护着第二个没有客户的产品。除非部署基础设施就是你的生意，否则把这套机制交给平台，让你的工程师回到只有他们才能完成的工作上吧。

希望你喜欢这篇文章。你可以在 LinkedIn (https://linkedin.com/in/manishmshiva)上与我联系。

免费学习编程。freeCodeCamp 的开源课程已帮助超过 40,000 人获得了开发者工作。开始学习 (https://www.freecodecamp.org/learn)