測試自動化與傳遞管線

您已了解何謂持續部署以及持續傳遞軟體和服務，但這兩者實際上是三角理論的一部分。 DevOps 實務旨在實現持續 整合、交付與部署。 這些做法通常依照這個順序累積，每一項都依前一項而定。

現在回頭來討論這三者中的第一個：整合。 開發程序是部署前的一部分。 DevOps 建議小組成員經常將程式碼整合至包含單一「主要」或「主幹」程式碼基底的共用存放庫，並將此習慣納入開發做法。 其目標是讓所有人員都能共同參與即將發行的程式碼，而非在各自的複本上工作，直到在最後一刻才將所有內容結合在一起。

然後，自動化測試可以確認每個小組成員的整合。 這項測試有助於判斷程式碼每次經過變更及新增之後是否「狀況良好」。 測試是所謂的 管道的一部分。 該單位其餘部分則專注於整合測試與交付流程。

持續交付管線

若要了解自動測試在持續傳遞部署模型中所扮演的角色，則必須思考自動測試如何融入傳遞管線。 持續傳遞管線是一系列步驟的實作，程式碼在開發程序中會經歷變更、取得認可，再部署至生產。 以下是簡化的傳遞管線範例步驟圖表:

一步步走過這條流程：

• 當程式碼或基礎架構的變更提交至程式碼存放庫時 (可能使用拉取請求)，流水線的執行個體就會啟動。

• 接著執行單元測試，通常接著是整合測試或端對端測試。 結果會回報給開啟拉取請求的開發者。

• 此階段，儲存庫中的程式碼通常會被掃描是否有秘密、漏洞和錯誤設定。

• 當所有項目檢查完畢後，即會建置程式碼並準備進行部署。

• 接下來，程式碼會部署到測試環境。 審查者可被通知新部署，以便檢視預生產解決方案。 審查者接著批准或拒絕升級到生產環境，這才啟動部署流程的最後階段，將程式碼釋放到生產環境。

您可在這個管線中，發現整合與部署之間的分界線。 標示的標記指出一些合乎邏輯的點，可以透過包含的邏輯與自動化，甚至可能的人為介入來停止管線。

持續整合與交付工具：Azure Pipelines 與 GitHub Actions

若要使用持續整合與持續傳遞，則需要適當的工具。 Microsoft 提供兩種第一方 CI/CD 選項用於建置與部署至 Azure：Azure Pipelines（Azure DevOps的一部分）與 GitHub Actions。 兩者都能自動化建置並持續測試你的程式碼，並且都能部署到 Azure 服務、虛擬機及其他雲端和本地目標。 許多團隊在原始碼已存於 GitHub 時採用 GitHub Actions，而 Azure Pipelines 仍是標準化 Azure DevOps 團隊的強力選擇。

本單元其餘部分聚焦於 Azure Pipelines，但 GitHub Actions 採用類似的高階概念，儘管術語有所不同。 在 GitHub Actions 中，工作流程包含作業和步驟，行動提供可重用的自動化，執行器則負責執行工作，而環境可以保護部署。

管線的輸入（你的程式碼或設定）存在於版本控制系統中，例如 GitHub 或其他 Git 供應商。

Azure Pipelines 運行於虛擬機或容器等運算系統，並提供 Microsoft 託管的建置代理程式，運行於 Windows、Linux 及 macOS。 當你需要完全掌控建置環境時，也可以註冊自己的自架代理。 它也提供與測試、安全及程式碼品質外掛的整合。最後，它很容易擴充，讓你能將自己的自動化帶入 Azure Pipelines。

管線是用 YAML 語法定義的，這些語法與你的程式碼一同存放在 Git 倉庫中。 YAML 管線是新專案的推薦方法。 Azure DevOps 中也提供經典使用者介面供舊有管線使用，但大多數新功能（包括容器工作及多項進階功能）僅支援 YAML。 管線也提供範本，讓你可以輕鬆建立管線，例如用於 Docker 映像檔或 Node.js 專案的範本。 您也可以重複使用現有的 YAML 檔案。

建立管線的基本步驟包括：

1. 設定 Azure Pipelines 以使用你的 Git 儲存庫。
2. 透過編輯 azure-pipelines.yml 檔案來定義你的建置（或對於舊有管線，使用經典編輯器）。
3. 將程式碼推送至版本控制存放庫。 此動作會觸發管線來建置並測試程式碼。

當程式碼經過更新、建置和測試之後，即可將其部署到任何想要的目標。

Azure 管線建構

管線的結構如下：

• 作業：作業是單一建置代理程式上執行的工作或步驟群組。 作業 (Job) 是您可以排程執行的最小工作元件。 作業中的所有步驟會依序執行。 這些步驟可以是你需要的任何行動，包括建置或編譯軟體、準備測試樣本資料、執行特定測試等等。

• 階段：階段是相關作業的邏輯群組。

每個管線都至少具有一個階段。 使用多個階段，將管線組織成大型單位，並在管線中為可暫停和執行檢查的點加上標記。

管線可根據需要變得簡單或複雜。 關於管線建構與使用的教學，請參考 Build 應用程式與 Azure DevOps 學習路徑。

環境可追蹤性

管線有一個與可靠性相關的層面值得一提。 您可以用這種方式來建立管線，以將生產環境中執行的內容與特定的建置執行個體相互關聯。 理想狀況下，你應該能追溯到某個特定的 pull request 或程式碼變更。 這種可追溯性在事件發生時非常寶貴，事後在事後檢視時，也在試圖找出哪些變更導致問題時非常寶貴。 有些 CI/CD 系統（像是 Azure Pipelines 和 GitHub Actions）讓這種關聯變得簡單，而有些則需要你手動建構一條管線，讓建置 ID 在每個階段中傳遞。