部署我們的應用程式

在這個專案的生命週期部分中，可能存在大量需要解決的問題。因此，建立能夠以儘可能少的手動干預處理這些問題的工具鏈非常重要。

以下是一些需要考慮的特定於此專案的因素：

• 生成生產版本：確保檔案已壓縮、分塊、應用了樹狀搖動，以及版本已“快取失效”。
• 執行測試：這些測試可以從“程式碼是否正確格式化？”到“這個東西是否按預期工作？”，並確保失敗的測試阻止部署。
• 將更新後的程式碼實際部署到即時 URL：或者可能是一個用於預釋出的暫存 URL，以便先進行審查。

以上任務還會進一步細分；請注意，大多數 Web 開發團隊都會對開發後階段的至少一部分使用自己的術語和流程。

對於這個專案，我們將使用 GitHub Pages 的免費靜態託管服務來託管我們的專案。它不僅在網際網路上為我們的網站提供服務，還為我們的網站提供了 URL。它很棒——許多 MDN 示例網站都託管在 GitHub Pages 上。

部署到託管通常是在專案生命週期的最後階段進行，但隨著 GitHub Pages 等服務的出現，降低了部署成本（從財務角度以及實際部署所需的時間來看），可以在開發過程中進行部署，以共享正在進行的工作或出於其他目的進行預釋出。

GitHub 提供了一個流暢的工作流程，將新程式碼轉換為即時網站

• 您將程式碼推送到 GitHub。
• 您定義了一個 GitHub Action，它會在主分支出現新推送時觸發，該 Action 會構建程式碼並將其放在特定位置。
• 然後 GitHub Pages 會在特定 URL 上提供該程式碼。

正是這些相互關聯的服務，我們鼓勵您在選擇自己的構建工具鏈時尋找。我們可以提交程式碼並推送到 GitHub，更新後的程式碼會自動觸發整個構建過程。如果一切順利，我們就會自動獲得一個即時更改的部署。我們唯一需要執行的操作是最初的“推送”。

但是，我們必須設定這些步驟，現在我們將對此進行介紹。

同樣，由於我們在開發中使用的是 Vite，因此構建選項非常容易新增。正如我們之前所看到的，我們已經有一個自定義指令碼 npm run build，它可以讓 Vite 構建所有準備投入生產的內容，而不是僅僅為了開發和測試目的而執行它。這包括對程式碼進行 壓縮 和 樹狀搖動，以及對檔名進行快取失效。

最佳實踐是始終在專案中定義一個 build 指令碼，這樣我們就可以依靠 npm run build 來始終執行完整的構建步驟，而無需記住每個專案的特定構建命令引數。

新建立的生產程式碼被放置在一個名為 dist 的新目錄中，該目錄包含執行網站所需的所有檔案，您可以將其上傳到伺服器。

但是，手動執行此步驟並不是我們的最終目標——我們希望構建能夠自動進行，並且 dist 目錄的結果能夠即時部署到我們的網站上。

本節將幫助您完成將程式碼儲存在 Git 儲存庫中的過程，但這遠遠不是 Git 教程。有很多優秀的教程和書籍可用，我們的 Git 和 GitHub 頁面是一個不錯的起點。

我們之前已經將工作目錄初始化為 Git 工作目錄。驗證這一點的一個快速方法是執行以下命令

git status

您應該會收到有關哪些檔案正在跟蹤、哪些檔案已暫存等的狀況報告——所有這些都是 Git 語法的一部分。如果您收到錯誤 fatal: not a git repository，則工作目錄不是 Git 工作目錄，您需要使用 git init 初始化 Git。

現在，我們面前有三個任務：

• 將我們所做的任何更改新增到暫存區（Git 將從該暫存區提交檔案的一個特殊名稱）。
• 將更改提交到儲存庫。
• 將更改推送到 GitHub。

1. 要新增更改，請執行以下命令
   bash

   git add .
   

   請注意結尾處的句號，它表示“此目錄中的所有內容”。git add . 命令有點像大錘——它會一次性新增您所做的所有本地更改。如果您希望更精細地控制要新增的內容，請使用 git add -p 進行互動式操作，或者使用 git add path/to/file 新增單個檔案。
2. 現在所有程式碼都已暫存，我們可以提交；執行以下命令
   bash

   git commit -m 'committing initial code'
   

   注意：雖然您可以在提交訊息中隨意寫任何內容，但網路上有一些關於優秀提交訊息的有用提示。保持簡短、簡潔和描述性，以便它們清楚地描述更改的作用。

3. 最後，程式碼需要推送到您託管在 GitHub 上的儲存庫中。我們現在就來做。在 GitHub 上，訪問 https://github.com/new，並建立您自己的儲存庫來託管此程式碼。
4. 為您的儲存庫起一個簡短、易記的名稱，其中不要包含空格（使用連字元分隔單詞），並新增一個描述，然後單擊頁面底部的“建立儲存庫”。您現在應該擁有一個指向您的新 GitHub 儲存庫的“遠端”URL。
5. 在我們將程式碼推送到該位置之前，需要將此遠端位置新增到我們的本地 Git 儲存庫中，否則它將無法找到它。您需要執行一個具有以下結構的命令（現在使用提供的 HTTPS 選項——特別是如果您是 GitHub 的新手——而不是 SSH 選項）
   bash

   git remote add origin https://github.com/your-name/repo-name.git
   

   因此，如果您的遠端 URL 是 https://github.com/remy/super-website.git，如上圖所示，您的命令將是
   bash

   git remote add origin https://github.com/remy/super-website.git
   

   將 URL 更改為您的儲存庫，並立即執行它。

   注意：在您選擇儲存庫名稱後，請確保 vite.config.js 中的 base 選項反映此名稱，如 上一章 中所述。否則，JavaScript 和 CSS 資產將無法正確連結。

6. 現在，我們準備將程式碼推送到 GitHub；現在執行以下命令
   bash

   git push origin main
   

   此時，系統會提示您輸入使用者名稱和密碼，然後 Git 才會允許進行推送。這是因為我們使用了 HTTPS 選項而不是 SSH 選項，如之前的螢幕截圖所示。為此，您需要您的 GitHub 使用者名稱，以及——如果您沒有啟用雙重身份驗證 (2FA)——您的 GitHub 密碼。我們始終建議您儘可能使用 2FA，但請記住，如果您使用 2FA，您還需要使用“個人訪問令牌”。GitHub 幫助頁面有一個 關於如何獲取令牌的出色且簡單的演練。

此最終命令指示 Git 將程式碼推送到我們稱為 origin 的“遠端”位置（即託管在 github.com 上的儲存庫——我們可以隨意命名它）並使用 main 分支。我們還沒有遇到分支，但“main”分支是我們的工作預設位置，也是 Git 開始的地方。當我們定義觸發構建網站的 Action 時，我們還將讓它監視“main”分支上的更改。

因此，我們的專案已提交到 Git 並推送到 GitHub 儲存庫中，工具鏈中的下一步是定義一個構建 Action，以便我們的專案可以即時部署到網路上！

GitHub Actions 與 ESLint 配置一樣，也是另一個需要深入研究的深奧話題。第一次嘗試很難做到正確，但對於諸如“構建靜態網站並將其部署到 GitHub Pages”之類的常見任務，有很多示例可以複製和貼上。您可以按照 使用自定義 GitHub Actions 工作流程釋出 中的說明進行操作。您可以檢視 我們的 GitHub Action 檔案 以獲取一個工作示例。（檔名稱無關緊要。）

將此檔案提交到主分支後，您應該會在提交標題旁邊看到一個小綠色的對勾

如果看到一個黃色圓點，則表示 Action 正在執行；如果看到一個紅色的叉號，則表示 Action 失敗。單擊圖示，您就可以看到自己的構建 Action（在本例中名為“Deploy build”）的狀態和日誌。

等待幾分鐘後，您就可以訪問您的 GitHub Pages URL，在網路上檢視您的即時網站。該連結類似於 https://<your-name>.github.io/<repo-name>。對於我們的示例，該連結位於 https://mdn.github.io/client-toolchain-example/。

現在，我們來介紹工具鏈中的最後一個環節：一個測試，以確保我們的程式碼正常工作。

測試本身是一個龐大的主題，即使是在前端開發領域也是如此。我將向您展示如何在專案中新增一個初始測試以及如何使用該測試來阻止或允許專案部署。

在進行測試時，有很多方法可以解決問題：

• 端到端測試，它涉及您的訪問者點選某個東西，然後發生其他事情。
• 整合測試，它基本上是說“當代碼塊連線到另一個程式碼塊時，它是否仍然有效？”
• 單元測試，對功能的細小部分進行測試，以檢視它們是否按預期執行。
• 還有很多其他型別。此外，請檢視我們的 跨瀏覽器測試模組，其中包含大量有用的測試資訊。

請記住，測試不僅限於 JavaScript；可以針對渲染後的 DOM、使用者互動、CSS 甚至頁面外觀執行測試。

但是，在這個專案中，我們將建立一個小的測試來檢查 GitHub API 資料是否處於正確的格式。如果不是，測試將失敗並阻止專案上線。除此之外的其他任何事情都超出了本模組的範圍——測試是一個巨大的主題，確實需要單獨的模組來處理。我們希望本節至少能讓你意識到測試的必要性，並種下種子，激勵你去學習更多。

測試本身並不重要。重要的是如何處理失敗或成功。因為我們正在編寫一個自定義的構建操作，所以我們可以在執行測試之前新增一個步驟。如果測試失敗，構建將失敗，部署將不會發生。

好訊息是：因為我們正在使用 Vite，Vite 已經提供了一個很好的整合測試工具：Vitest。

讓我們開始吧。

1. 安裝 Vitest
   bash

   npm install --save-dev vitest
   

2. 在你的 package.json 中，找到你的 scripts 成員，並更新它，使其包含以下測試和構建命令
   json

   "scripts": {
     // …
     "test": "vitest"
   }
   

   注意：這是使用 Vite 與 Vitest 的好處：如果你使用其他測試框架，你需要新增另一個配置來描述如何轉換測試檔案，但 Vitest 會自動使用 Vite 配置。

3. 現在，我們當然需要將測試新增到我們的程式碼庫中。通常，如果你正在測試某個檔案的函式，比如 App.jsx，你可以在它旁邊新增一個名為 App.test.jsx 的檔案。在本例中，我們只是在測試資料，所以讓我們建立一個另一個目錄來存放我們的測試。你可以開啟你在上一章下載的示例倉庫，並將 tests 資料夾複製過來。
4. 現在要手動執行測試，我們可以在命令列中執行
   bash

   npm run test
   

   你應該看到類似於這樣的輸出

   > client-toolchain-example@1.0.0 test
   > vitest
   
   
   DEV  v1.6.0 /Users/joshcena/Desktop/work/Tech/projects/mdn/client-toolchain-example
   
   ✓ tests/api.test.js (1) 896ms
     ✓ GitHub API returns the right response 896ms
   
   Test Files  1 passed (1)
        Tests  1 passed (1)
     Start at  23:12:25
     Duration  1.03s (transform 15ms, setup 0ms, collect 5ms, tests 896ms, environment 0ms, prepare 38ms)
   
   
   PASS  Waiting for file changes...
         press h to show help, press q to quit
   

   這意味著測試通過了。就像 Vite 一樣，它會監控更改並在你儲存檔案時重新執行測試。我們可以按 q 退出。
5. 我們仍然需要將測試連線到我們的構建操作，這樣如果測試失敗，它就會阻止構建。開啟 .github/workflows/github-pages.yml 檔案（或你為構建操作指定的任何檔名）並新增以下步驟，就在執行 npm run build 的步驟之前
   yaml

   - name: Install deps
     run: npm ci
   
   # Add this
   - name: Run tests
     run: npm run test
   
   - name: Build
     run: npm run build
   

   這將在構建步驟之前執行測試。如果測試失敗，構建將失敗，部署將不會發生。
6. 現在讓我們使用與之前類似的命令將新程式碼上傳到 GitHub
   bash

   git add .
   git commit -m 'adding test'
   git push origin main
   

   在某些情況下，你可能想測試構建程式碼的結果（因為這並不完全是我們編寫的原始程式碼），因此可能需要在構建命令之後執行測試。在你自己的專案中工作時，你需要考慮所有這些單獨的方面。

最後，在推送後一分鐘左右，GitHub Pages 將部署專案更新。但只有在通過了引入的測試的情況下才會部署。

這就是我們的示例案例研究和模組的全部內容！我們希望你發現它有用。雖然要成為一名客戶端工具大師還有很長的路要走，但我們希望本模組能讓你邁出理解客戶端工具的第一步，並讓你有信心學習更多、嘗試新事物。

讓我們總結工具鏈的所有部分

• 程式碼質量和維護由 ESLint 和 Prettier 執行。這些工具作為 devDependencies 透過 npm install --dev eslint prettier eslint-plugin-react ...（由於這個專案使用 React，所以需要 ESLint 外掛）新增到專案中。
• 程式碼質量工具讀取兩個配置檔案：eslint.config.js 和 .prettierrc。
• 在開發過程中，我們繼續使用 npm 新增依賴項。Vite 開發伺服器在後臺執行，以監控更改並自動構建我們的原始碼。
• 部署透過將我們的更改推送到 GitHub（在 "main" 分支上）來處理，這會觸發使用 GitHub Actions 構建和部署以釋出專案。對於我們的例項，這個 URL 是 https://mdn.github.io/client-toolchain-example/；你將有自己的唯一 URL。
• 我們還有一個簡單的測試，如果 GitHub API 提要沒有提供正確的格式資料，它就會阻止站點構建和部署。

對於那些想要挑戰的人來說，可以考慮是否可以最佳化這個工具鏈的某些部分。一些需要問自己的問題

• 我們是否可以只提取 plotly.js 中我們需要的功能？這將減少 JavaScript 包的大小。
• 也許你想新增其他工具，比如用於型別檢查的 TypeScript，或者用於 CSS 規範檢查的 stylelint？
• 是否可以將 React 替換為 更小的東西？
• 是否可以新增更多測試以防止錯誤的構建部署，比如 效能稽核？
• 是否可以設定通知，讓你知道新部署成功或失敗？

• 上一個
• 概述：瞭解客戶端 Web 開發工具