选择我们的工具

本章的目的，是让你亲身体验一下：在每一次提交到主分支时，真正把应用部署出去意味着什么。

这也是为什么我们会在第五章就开始谈论部署：为了让你从现在开始，就能在后续章节不断练习这块“肌肉”，就像在一个真实的商业项目中会做的那样。

我们尤其关心的是：持续部署这一工程实践，会如何影响我们的设计决策与开发习惯。

当然，构建一个完美的持续部署流水线并不是本书的重点——那本身就足以写成一本书，甚至需要一整家公司来专注解决。

因此，我们必须务实，在“实用价值”（例如学习到业界广泛使用的工具）与“开发者体验”之间找到平衡。

即便我们现在花费大量精力去拼凑出一个所谓“最佳”的部署方案，等你真正落地到工作中，还是很可能会因为组织的具体限制而选择不同的工具和服务商。

真正重要的是其背后的理念，以及让你能够亲自实践“持续部署”这种方法论。

Docker 这一块

我们的本地开发环境和生产环境，其实承担着截然不同的角色。

在本地机器上，浏览器、IDE，甚至我们的音乐播放列表都能和平共处——它是一个多用途的工作站。而生产环境则不同，它的关注点非常单一：运行我们的软件，并让用户能够访问。任何与这个目标无关的东西，轻则浪费资源，重则成为安全隐患。

这种差异，长期以来让“部署”变得非常棘手，也催生了一个经典的抱怨——“在我机器上能跑啊！”。

仅仅把源代码拷贝到生产服务器上是远远不够的。我们的软件往往会依赖一些前提条件，比如：

操作系统的能力：一个原生的 Windows 应用无法在 Linux 上运行。

额外软件的可用性：比如特定版本的 Python 解释器。

系统配置：例如是否拥有 root 权限。

即便我们最初在本地和生产搭建了两套完全一致的环境，随着时间推移，版本的漂移和细微的不一致，依然会在某个深夜或周末“突然反噬”。

确保软件能够稳定运行的最简单方式，就是严格控制它所运行的环境。

这就是虚拟化技术的核心理念：与其把代码“运”到生产环境，不如直接把包含应用的自给自足的环境一同打包送过去！

这样一来，双方都能获益：

对开发者来说，周五晚上少了许多意外。

对运维来说，得到的是一个稳定、一致的抽象层，可以在其上进一步构建。

如果这个环境本身还能用代码来定义，从而确保可复现性，那就更完美了。

好消息是：虚拟化早已不是什么新鲜事，它已经普及了将近十年。

像技术领域的多数情况一样，你会有多种选择：

在本书中，我们会选择最主流、最普及的方案——Docker 容器。

AWS、Google Cloud、Azure、Digital Ocean、Clever Cloud、Heroku、Qovery…… 你可以选择的软件托管服务商名单还远不止这些。

如今，甚至有人专门靠“根据你的需求和场景推荐最合适的云服务”做起了生意——不过，这既不是我的工作（至少现在还不是），也不是这本书的目的。

我们要寻找的，是易于使用（良好的开发者体验、尽量少的无谓复杂性），同时又相对成熟可靠的解决方案。

在 2020 年 11 月，满足这两个条件的交集似乎就是 Digital Ocean，尤其是他们新推出的 App Platform 服务。

声明：Digital Ocean 没有付钱让我在这里推广他们的服务。