一旦开发者为网站编写了代码，就需要将其部署到 Web 服务器上。这个过程称为代码部署。
“代码完成”是软件开发人员在完成一个开发项目时常用的说法。
但代码完成并不意味着一切结束。一旦开发者为网站编写了代码，就需要将该代码放置到 Web 服务器上。这被称为代码部署。它可能包括修复错误的代码、添加新功能或升级底层平台的代码。通常它是这三者的结合。
在新代码部署之前，网站的访问者将无法使用它或从中受益。
部署风险
停机时间通常是部署中的主要风险。一些网站可以快速接受新代码并在几秒钟内投入使用。而另一些则需要计划维护窗口，并需要数十名员工花费数小时协助。我听说过有些商店每年只部署几次。这些往往是非常庞大的工程，会对业务产生重大影响。
部署相关的风险在于可能会引入新的错误。根据部署前测试的质量与数量，新特性或现有功能中都可能发现错误。根据错误的严重程度及其影响范围，有时可能需要回滚部署，即撤销所有新代码并恢复到旧版本，这被称为回滚。
回滚的成功与否取决于开发人员如何规划部署。规划良好的部署通常可以轻松回滚。但有些部署根本无法回滚。
高压力
部署往往带来巨大的压力。一次失败的部署可能导致商店乃至整个业务遭受损失甚至失败。有许多方法可以使部署更简单、更安全、压力更小。
事实上，使部署更安全、压力更小的最佳方式恰恰是反直觉的：更频繁地进行部署。部署越频繁，团队获得的经验就越多。通过重复实践，团队可以提高其部署技能，即使出现错误也能应对。
更频繁部署的一个附带好处是，每次部署的代码量会减少。例如，假设一家公司本季度有 60 项代码更改需要构建和部署。该公司可以一次性编写所有 60 项更改的代码，然后一次性部署。但这存在风险，因为 60 个同时进行的更改更有可能引发问题。
或者，该公司可以每月部署一次。这样每次部署包含 20 项更改，潜在需要排查的问题较少。或者该公司可以每周部署一次。这样每次部署仅包含五项更改。
许多前沿公司部署得更加频繁，有时每天多次。据报道，Amazon 每 11.6 秒就会进行一次部署。
更频繁地部署代码的最大好处是有助于您的客户。如果新代码是为客户设计的，那么立即部署是有意义的。而且带来的好处——比如更好的结账流程、改进的产品推荐，甚至是新的菜单——也将有助于业务发展。
我的部署流程
作为示例，我将代码部署到我的 Shopify 应用的流程如下。
一旦我编写并测试完单个代码更改，我就会进行部署。可能每周只部署一次，也可能一天内部署多达六次。
由于每次部署都只针对单个更改，因此很容易发现是否出现了故障、性能下降或其他影响应用其余部分的问题。有时部署只是为了让系统为后续的更改做好准备，这些操作对客户来说并不总是可见的。
这一流程极大地帮助了客户服务，因为应用用户提交一个想法后，在当天结束之前该想法就可能上线。
关键问题
与团队就他们的部署流程展开对话是了解该流程的最佳方式。首先提出两个问题：
- “完成一次部署需要多长时间？”
- “部署的频率如何？”
通常，如果完成一次部署所需时间超过60分钟，或者部署频率为每月一次（或更低），则有很大的改进空间。务必追问“为什么”，并且重要的是，“如何改进？”