使用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上聯絡。