今天我們要來聊聊，測試寫完之後，該如何讓測試是具有強制力，並且實際融入開發流程中，能夠持續進行迭代的方法。

在目前的工作經驗中發現在CI Pipeline中進行測試是個很好的方式，比如PR的時候就可以綁定測試的通過率或是coverage作為其中一項檢核標準，用以確保推上版控的程式碼都有進行測試。

那麼首先，什麼是CI呢?

其實 CI 和另外一個名詞是一組的，也就是 CI/CD。

什麼是 CI/CD

CI/CD 指「持續整合（Continuous Integration）和 持續交付/部署（Continuous Delivery/Deployment）」的縮寫。
首先 持續整合（Continuous Integration）的核心概念是把開發者的Code 頻繁，定期的倂回主程式中。並且每當有人推新的 Code 上來的時候，部屬好的自動化工具會對程式碼自動進行 編譯、測試。以確保程式碼符合品質要求且不會破壞既有的功能。

CI可以幫助我們，透過每次提交就進行的測試即時發現錯誤，同時提升程式的品質。

持續交付（CD, Continuous Delivery）則是指開發完成的代碼可以隨時部署到生產環境。觸發點可以是手動抑或是排程。重點是，整個打包過程都已經自動化。

而持續部署（CD, Continuous Deployment）則是在進一步延伸，不只是打包，而是將整個自動化流程一直延伸到，自動將程式碼部署到PROD環境。CD的好處是，減少版本更新時的時間和人為操作的失誤。

那麼具體來說整個流程大概是如何執行的呢?

CI/CD 工作流程

1. 開發者將代碼提交到版本控制系統

• 版本控制系統：通常使用 Git 作為版本控制工具。開發者在本地編寫代碼，完成新的功能或修復 Bug 後，將代碼提交（git commit）並推送（git push）到雲端的專案管理服務(ex: Azure, GitHub 等)。
• 分支策略：多人協做的時候會使用 Git 的分支來管理不同階段的開發。於是，當我們完成一個功能，會通過 Pull Request 將代碼合併到主幹分支中。

2. CI 工具自動提取代碼並執行編譯和測試

• CI 工具：當代碼被提交或合併到指定分支時，CI 工具會自動檢測到代碼的更新，並啟動一個新的 CI Pipeline（流水線）。該流水線包含一系列步驟，如代碼檢查、編譯和測試。
• 代碼檢查：CI 流程可能首先會進行一些靜態代碼分析，這些工具（如 ESLint、SonarQube、Checkstyle）會檢查代碼格式、潛在的 Bug 或安全問題。
• 編譯：CI 工具會自動執行編譯任務，將代碼轉換為可執行的二進制文件。
• 自動化測試：CI 工具會自動運行單元測試、集成測試和功能測試，確保新代碼不會破壞現有功能，並且其自身功能正常。測試框架如 JUnit、Selenium 等可以自動化測試過程。當所有測試成功通過後，代碼才被視為合格。
• 失敗處理：如果在編譯或測試過程中發現錯誤，CI 工具會即時通知開發者，通常會通過電子郵件、Slack 等方式發送失敗報告。開發者可以檢查錯誤日誌，修復問題，並重新提交代碼以重啟 CI 流程。

3. 若測試通過，CD 工具自動進行打包並部署到測試或生產環境

• 打包（Build）：在測試通過後，CD 工具會進行打包過程。這通常包括將代碼、資源文件、配置文件等組合成一個可部署的工件（artifact）。這些工件可以是 Docker 映像、可執行文件、壓縮包等，具體取決於應用的類型。
• 部署到測試環境：打包完成後，CD 流程會自動將工件部署到測試環境中。測試環境通常是一個接近生產環境的模擬環境，允許 QA 團隊或自動化測試系統進行進一步的驗證，如端到端測試（E2E）、性能測試和用戶驗收測試（UAT）。

4. 在持續部署的情況下，驗證完成後，自動部署到生產環境

• 持續交付（Continuous Delivery）：在持續交付的情況下，當代碼通過所有測試和驗證後，它就準備好可以部署到生產環境了。通常，在這個階段還是會有人為的批准步驟，手動選擇何時將代碼推送到生產環境。部署的過程已經完全自動化，但最終的觸發還需要手動進行，確保業務團隊可以選擇合適的時間進行更新。
• 持續部署（Continuous Deployment）：如果是持續部署，則整個流程無需人工干預，當代碼通過所有自動測試後，CD 工具會自動將更新發布到生產環境。這意味著每次合併到主幹分支的代碼都會立即進行自動發布。

5. 生產環境監控與反饋

• 監控與反饋：在應用部署到生產環境後，團隊會監控其運行情況，以確保應用在實際運行中的性能和穩定性。(ex:Grafana)來完成，監控應用的性能指標、錯誤日誌等，並發出警報。如果發現問題，可以快速進行回滾或修復。

用一行簡單的敘述來表示 CI/CD 的話，大致上會像是這樣。

***提交程式碼 -> CI(編譯與測試) -> CD(打包和部屬) -> 在測試環境中進行驗收測試 -> 部屬到正式環境 **

如何在Azure Pipeline 中運行前端測試

在了解了CI/CD大致在做什麼之後，我們就來嘗試將我們寫好的前端測試，於Azure Pipeline中運行。而CI pipeline中，通常會以專案中的yaml檔作為執行腳本。pipeline運行的時候，就會按照yaml腳本中的步驟一步一步進行。

以下是一些常用的語法。

1. trigger

trigger:
  branches:
    include:
      - main

• 作用: 定義何時觸發 CI Pipeline。這裡指定了 main 分支，表示當有代碼推送到 main 分支時，Pipeline 將會自動運行。
• 關鍵字:
  • branches: 定義要監視的分支。
  • include: 表示包含哪些分支來觸發 Pipeline。

2. pool

pool:
  vmImage: 'ubuntu-latest'

• 作用: 定義了 Azure DevOps 中運行 CI Pipeline 的代理機器的環境。這裡指定了使用最新的 Ubuntu 作為運行環境。
• 關鍵字:
  • vmImage: 設定要使用的虛擬機操作系統映像。可選值包括 'ubuntu-latest', 'windows-latest', 'macOS-latest' 等。

3. steps

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '16.x'
    displayName: 'Install Node.js'

• 作用: steps 包含了一系列步驟，這些步驟定義了在 Pipeline 中要執行的操作。每個步驟可以是腳本、任務或者其他操作。

3.1 task

- task: NodeTool@0
  inputs:
    versionSpec: '16.x'

• 作用: 使用 Azure DevOps 中的 NodeTool 任務來安裝特定版本的 Node.js。
• 關鍵字:
  • task: 指定要運行的 Azure DevOps 任務名稱。這裡使用了 NodeTool@0，表示安裝 Node.js 工具。
  • inputs: 提供給任務的輸入參數。
  • versionSpec: 指定要安裝的 Node.js 版本，16.x 表示安裝 Node.js 16 的最新版本。

3.2 script

- script: |
    npm install -g @angular/cli
    npm install
  displayName: 'Install dependencies'

• 作用: script 用於執行一段自定義的命令行腳本。在這裡，它用來安裝 Angular CLI 和項目依賴。
• 關鍵字:
  • script: 定義要執行的命令行腳本。可以是一個或多行命令，用 | 符號表示多行腳本。
  • displayName: 為此步驟設置一個友好的名稱，便於在 Azure Pipelines 的 UI 中識別此步驟。

下方就是一個建立pipeline的簡單操作手順:

1. 登錄到 Azure DevOps，進入你的專案。

2. 進入 Pipelines，然後點選 Create Pipeline。

3. 選擇Repo

4. 選擇 Starter pipeline，然後編輯 azure-pipelines.yml 文件。

5. 配置 azure-pipelines.yml

   這個文件用來定義 Azure Pipeline 如何運行你的 CI/CD 流程。
   以Angular專案來說，CI基本會包含裝依賴、執行測試、打包測試

trigger:
  branches:
    include:
      - main  # 設定觸發分支，例如 main 分支

pool:
  vmImage: 'ubuntu-latest'

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '16.x'  # 安裝 Node.js 的版本
    displayName: 'Install Node.js'

  - script: |
      npm install -g @angular/cli
      npm install
    displayName: 'Install dependencies'

  - script: |
      ng lint
    displayName: 'Run linter'

  - script: |
      ng test --watch=false --browsers=ChromeHeadless
    displayName: 'Run unit tests'

  - script: |
      ng build --prod
    displayName: 'Build Angular app'

• NodeTool@0: 安裝 Node.js，這是運行 Angular 應用所需的。
• Install dependencies: 使用 npm install 安裝項目所需的依賴項。
• ng lint: 執行 Angular 的 linter 確保代碼風格一致性。
• ng test: 執行單元測試，並將瀏覽器設定為 ChromeHeadless，因為這是 Azure 上 CI 執行環境所需的無頭模式。
• ng build --prod: 在 production 模式下編譯 Angular 應用程式，確認能正常打包。

6. 完成 azure-pipelines.yml 的編輯後，提交並推送到你的 repo。
7. 最後只要等待pipeline運行完畢就可以看到測試結果。

可以發現其實大部分的事情，託管平台都幫我們做好了，其實要建立pipeline是非常容易的，且大部分的託管平台都有詳細的手順和文件說明。所以我認為重要的是，了解背後為什麼要導入，概念是什麼，優劣是什麼。

到這邊我們基本上也把整個前端的開發流程跑完一輪了，希望可以做為一個敲門磚，給大家一些方向，一些關鍵字下去搜尋。其實每個階段要研究下去還有太多太多細節和知識了。讓我們一起加油!! 繼續努力精進吧!!