跳到内容

c

部署

在写好了一个漂亮的应用之后,是时候考虑我们如何将其部署到真正的用户中去了。

在本课程的第三章节中,我们通过简单的推送git仓库到云提供商Heroku的服务器来实现。至少与许多其他类型的托管设置相比,在Heroku中发布软件是相当简单的,但它仍然包含风险:没有什么能阻止我们意外地将破损的代码推到生产中。

接下来,我们要看一下安全部署的原则,以及在小规模和大规模部署软件的一些原则。

Anything that can go wrong...

我们想定义一些关于我们的部署过程应该如何工作的规则,但在这之前,我们必须看看现实的一些限制。

"墨菲定律 "的一个措辞认为。

"任何可能出错的事情都会出错。"

当我们计划我们的部署系统时,记住这一点很重要。我们需要考虑的一些事情可能包括。

-如果我的电脑在部署过程中崩溃或挂起怎么办?

  • 我连接到服务器并通过互联网进行部署,如果我的互联网连接中断了会怎样?

  • 如果我的部署脚本/系统中的任何特定指令失败会怎样?

  • 如果由于某种原因,我的软件在我部署的服务器上不能按预期工作,会发生什么?我可以回滚到以前的版本吗?

  • 如果一个用户在我们进行部署之前对我们的软件做了一个HTTP请求(我们没有时间向用户发送响应)会发生什么?

这些只是部署过程中可能出错的一小部分,或者说,我们应该计划的事情。无论发生什么,我们的部署系统都绝不应该让我们的软件处于破碎状态。我们也应该总是知道(或者很容易找到)一个部署处于什么状态。

当涉及到部署(和一般的CI)时,要记住的另一个重要规则是。

"无声的失败是非常糟糕的!"

这并不意味着故障需要显示给软件的用户,它意味着如果有什么问题,我们需要意识到。如果我们意识到一个问题,我们就可以修复它,如果部署系统没有给出任何错误,但却失败了,我们可能最终会陷入这样一种状态:我们认为我们已经修复了一个关键的错误,但部署却失败了,把这个错误留在了我们的生产环境中,而我们却没有意识到这种情况。

What does a good deployment system do?

为部署系统定义明确的规则或要求是困难的,无论如何让我们尝试一下。

  • 我们的部署系统应该能够在部署的任何步骤中优雅地失败。

  • 我们的部署系统应该永远不会让我们的软件处于崩溃状态。

  • 我们的部署系统应该让我们知道何时发生了故障。通知失败比通知成功更重要。

  • 我们的部署系统应该允许我们回滚到以前的部署。

  • 与全面部署相比,这种回滚最好更容易做到,而且不容易失败。

  • 当然,最好的选择是在部署失败的情况下自动回滚

  • 我们的部署系统应该处理用户在部署之前/期间发出HTTP请求的情况。

  • 我们的部署系统应该确保我们正在部署的软件符合我们为此设定的要求(例如,如果没有运行测试就不要部署)。

让我们在这个假设的部署系统中也定义一些我们**想要的东西。

  • 我们希望它是快速的

  • 我们希望在部署期间没有停机时间(这与我们在部署之前/期间处理用户请求的要求不同)。