使用TypeScript、PostgreSQL和Prisma的后端：持续集成与部署

简介

本系列旨在通过解决一个具体问题来探索和展示现代后端开发的不同模式、问题和架构：一个在线课程评分系统。 选择这个问题是因为它涉及多种关系类型，并且足够复杂，足以代表一个真实世界的用例。

实时流的录像在上方提供，其内容与本文相同。

本系列将涵盖的内容

本系列将侧重于数据库在后端开发各个方面的作用，包括

在第一篇文章中，您为问题域设计了一个数据模型，并编写了一个种子脚本，该脚本使用Prisma Client将数据保存到数据库中。

在本系列的第二篇文章中，您在第一篇文章的数据模型和Prisma 模式之上构建了一个REST API。您使用Hapi构建了 REST API，这允许通过 HTTP 请求对资源执行 CRUD 操作。

在本系列的第三篇文章中，您实现了基于电子邮件的无密码身份验证和授权，使用JSON Web Tokens (JWT) 与 Hapi 结合来保护 REST API。此外，您还实现了基于资源的授权，以定义用户可以执行的操作。

今天您将学到什么

在本文中，您将通过定义一个运行测试并将后端部署到 Heroku 的工作流，来设置 GitHub Actions 作为 CI/CD 服务器，您将在 Heroku 上托管后端和 PostgreSQL 数据库。

Heroku 是一个平台即服务 (PaaS)。与无服务器部署模型相比，使用 Heroku，即使没有请求，您的应用程序也会持续运行。虽然无服务器具有许多优势，例如更低的成本和更少的运营开销，但这种方法避免了数据库连接流失和冷启动的挑战，这些是无服务器方法常见的挑战。

要了解有关使用 Prisma 应用程序部署范式之间的权衡，请查阅Prisma 部署文档。

注意： 在整个指南中，您会发现各种检查点，它们使您能够验证是否正确执行了步骤。

先决条件

要使用 GitHub Action 将后端部署到 Heroku，您需要以下内容

• Heroku 账户。
• Heroku CLI 已安装。
• 用于发送电子邮件的SendGrid API 令牌，您在本系列第 3 部分中创建了它。

持续集成和持续部署

持续集成 (CI) 是一种将个人开发人员的工作集成到主代码仓库中的技术，以便尽早发现集成错误并加速协作开发。通常，CI 服务器连接到您的 Git 仓库，每当提交被推送到仓库时，CI 服务器都会运行。

持续部署 (CD) 是一种关注自动化部署过程的方法，以便可以快速一致地部署更改。

尽管 CI 和 CD 涉及不同的职责，但它们相互关联，并且通常使用相同的工具进行处理。在本文中，您将使用 GitHub Actions 来处理 CI 和 CD。

持续集成管道

在持续集成中，主要的构建块是管道。管道是您定义的一组步骤，旨在确保您的更改不会引入错误或回归。例如，管道可能包含运行测试、代码检查工具和 TypeScript 编译器的步骤。如果其中一个步骤失败，CI 服务器将停止并将失败的步骤报告回 GitHub。

在团队中使用拉取请求引入代码更改时，CI 服务器通常会配置为自动为每个拉取请求运行管道。

您在前面步骤中编写的测试通过模拟对 API 端点的请求来工作。由于这些端点的处理程序与数据库交互，因此在测试期间您将需要一个带有后端模式的 PostgreSQL 数据库。在下一步中，您将配置 GitHub Actions 来运行一个测试数据库（在 CI 运行期间）并运行迁移，以便测试数据库与您的 Prisma 模式保持一致。

注意： CI 的有效性取决于您编写的测试质量。如果您的测试覆盖率很低，通过测试可能会产生虚假的安全感。

使用 GitHub Actions 定义工作流

GitHub Actions 是一个自动化平台，可用于持续集成。它提供了一个 API，用于根据 GitHub 中的事件编排工作流，并可用于从 GitHub 构建、测试和部署您的代码。

要配置 GitHub Actions，您需要使用 YAML 定义工作流。工作流可以配置为在不同的仓库事件上运行，例如，当提交被推送到仓库时或当拉取请求被创建时。

每个工作流可以包含多个作业，每个作业定义多个步骤。作业的每个步骤都是一个命令，并且可以访问正在测试的特定提交的源代码。

注意： CI 服务对管道使用不同的术语；例如，GitHub Actions 使用工作流一词来指代相同的事物。

在本文中，您将使用仓库中的grading-app 工作流。

让我们看一下这个工作流

grading-app 工作流包含两个作业：test 和 deploy。

test 作业将执行以下操作

1. 检出仓库。
2. 配置 Node。
3. 安装依赖项。
4. 在使用 services 启动的测试数据库中创建数据库模式。
5. 运行测试。

注意： services 可用于运行其他服务。在上面的测试作业中，它用于创建测试 PostgreSQL 数据库。

deploy 作业将执行以下操作

1. 检出仓库
2. 安装依赖项
3. 对生产数据库运行迁移
4. 部署到 Heroku

注意： on: push 将对每次提交触发工作流。条件 if: github.event_name == 'push' && github.ref == 'refs/heads/master' 确保 deploy 作业仅在 master 分支上触发。

分叉仓库并启用工作流

首先分叉GitHub 仓库，以便您可以配置 GitHub Actions。

注意： 如果您已经分叉了仓库，请从源仓库的 master 分支合并更改。

分叉后，前往 GitHub 上的Actions（操作）选项卡

通过点击启用按钮来启用工作流

现在，当您向仓库推送提交时，GitHub 将运行该工作流。

Heroku CLI 登录

确保您已使用 CLI 登录 Heroku

创建 Heroku 应用程序

要将后端应用程序部署到 Heroku，您需要创建一个 Heroku 应用程序。从克隆的仓库文件夹中运行以下命令

注意： 请使用您选择的唯一名称，而不是 YOUR_APP_NAME。

检查点 Heroku CLI 应记录应用程序已成功创建。

在 Heroku 上配置 PostgreSQL 数据库

使用以下命令创建数据库

检查点：要验证数据库是否已创建，您应该看到以下内容

注意： Heroku 将自动为应用程序运行时设置 DATABASE_URL 环境变量。Prisma Client 将使用 DATABASE_URL，因为它与Prisma 模式中配置的环境变量匹配。

在 GitHub 中定义构建时秘密

为了让 GitHub Actions 运行生产数据库迁移并将后端部署到 Heroku，您将在GitHub中创建工作流中引用的四个秘密。

注意： 构建时秘密和运行时秘密之间存在区别。构建时秘密将在 GitHub 中定义，并在 GitHub Actions 运行期间使用。另一方面，运行时秘密将在 Heroku 中定义并由后端使用。

秘密

• HEROKU_APP_NAME：您在上一步中选择的应用程序名称。
• HEROKU_EMAIL：您在注册 Heroku 时使用的电子邮件。
• HEROKU_API_KEY：Heroku API 密钥
• DATABASE_URL：Heroku 上的生产 PostgreSQL URL，在部署前运行生产数据库迁移所需。

获取生产 DATABASE_URL

要获取 Heroku 在配置数据库时设置的 DATABASE_URL，请使用以下 Heroku CLI 命令

检查点： 您应该在输出中看到 URL，例如 postgres://username:password@ec2-12.eu-west-1.compute.amazonaws.com:5432/dbname

获取 HEROKU_API_KEY

Heroku API 密钥可以从您的Heroku 账户设置中检索。

在 GitHub 中创建秘密

要创建这四个秘密，请前往仓库设置并打开Secrets（秘密）选项卡

点击New secret（新建秘密），使用名称字段作为秘密名称，例如 HEROKU_APP_NAME，并设置值

检查点： 创建这四个秘密后，您应该看到以下内容

在 Heroku 上定义环境变量

后端需要三个秘密，这些秘密将在运行时作为环境变量传递给应用程序

• SENDGRID_API_KEY：SendGrid API 密钥。
• JWT_SECRET：用于签署 JWT 令牌的秘密。
• DATABASE_URL：Heroku 自动设置的数据库连接 URL。

注意： 您可以通过在终端中运行以下命令来生成 JWT_SECRET：node -e "console.log(require('crypto').randomBytes(256).toString('base64'));"

要使用 Heroku CLI 设置它们，请使用以下命令

检查点： 要验证环境变量是否已设置，您应该看到以下内容

触发工作流以运行测试和部署

配置好工作流、在 Heroku 上创建好应用程序并设置好所有秘密后，您现在可以触发工作流来运行测试和部署。

要触发构建，请创建一个空提交并推送它

推送提交后，转到您的 GitHub 仓库的 Actions（操作）选项卡，您应该看到以下内容

点击表中带有提交消息的第一行

查看 test 作业的日志

要查看 test 作业的日志，请点击 test，这将允许您查看测试结果

验证到 Heroku 的部署

要验证 deploy 作业是否成功部署到 Heroku，请点击左侧的 deploy 并展开 Deploy to Heroku 步骤。您应该在日志末尾看到以下行

要从浏览器访问 API，请在克隆的仓库文件夹中运行以下 Heroku CLI 命令

这将打开浏览器并指向 https://YOUR_APP_NAME.herokuapp.com/。

检查点：您应该在浏览器中看到 {"up":true}，这由状态端点提供服务。

查看后端日志

要查看后端的日志，请在克隆的仓库文件夹中使用以下 Heroku CLI 命令

测试登录流程

要测试登录流程，您需要向 REST API 发出两次调用。

首先获取 API 的 URL

使用 curl 对登录端点进行 POST 调用

检查电子邮件中的 8 位数字令牌，然后进行第二次调用

检查点： 响应应具有 200 成功状态码，并包含带有 JWT 令牌的 Authorization 标头

总结

您的后端现已部署并正在运行。干得好！

您通过定义 GitHub Actions 工作流、创建 Heroku 应用程序、配置 PostgreSQL 数据库，并使用 GitHub Actions 将后端部署到 Heroku，从而配置了持续集成和部署。

当您通过提交到仓库并推送更改来引入新功能时，测试和 TypeScript 编译器将自动运行，如果成功，后端将被部署。

您可以通过访问 Heroku 控制面板来查看内存使用、响应时间和吞吐量等指标。这对于了解后端如何处理不同流量很有用。例如，后端负载越大，响应时间可能会越慢。

通过将 TypeScript 与Prisma Client结合使用，您可以消除通常在运行时检测到并涉及调试的一类类型错误。

您可以在GitHub上找到后端的完整源代码。

虽然 Prisma 旨在简化关系数据库的工作，但了解底层数据库和Heroku 特定细节仍然很有用。

如果您有任何问题，请随时在Twitter上联系。