測試自動化與傳遞管線

已完成

您已了解何謂持續部署以及持續傳遞軟體和服務,但這兩者實際上是三角理論的一部分。 DevOps 做法的目標是要實現持續「整合、部署和傳遞」

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

然後,自動化測試可以確認每個小組成員的整合。 這項測試有助於判斷程式碼每次經過變更及新增之後是否「狀況良好」。 該測試即所謂的 [管線] 一部分。 因為本單元將著重於整合式測試與傳遞管線,所以我們接下來將開始討論何謂管線。

持續傳遞管線

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

圖表中描繪出具有 8 個階段的管線,其中 4 個標示為整合,另外 4 個標示為部署,並以紅色指標箭號指向測試與檢閱階段

讓我們逐步解說這個管線。

  • 當程式碼或基礎結構的變更認可至程式碼存放庫時 (可能透過提取要求),就會啟動管線的執行個體。

  • 隨即會執行單元測試 (可能為整合或端對端測試),理想情況下,這些測試結果會傳回給提出測試要求的合作對象。

  • 此時,存放庫中的程式碼會針對祕密、弱點和設定層面等接受掃描。

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

  • 接下來,程式碼會部署到測試環境。 人員可能會收到新部署的通知,以便檢查進入生產階段前的解決方案。 如此一來,該名人員就可核准或拒絕部署生產、這會開始部署程序的最後一步,也就是將程式碼發行至生產。

您可在這個管線中,發現整合與部署之間的分界線。 紅色標記代表合乎邏輯的介入位置,您可在這些階段透過內含的邏輯與自動化或甚至人為介入來停止管線。

持續整合與持續傳遞的工具: Azure Pipelines

若要使用持續整合與持續傳遞,則需要適當的工具。 Azure Pipelines 是 Azure DevOps Services 的一部分,其可供用來自動建置並一致地測試程式碼。 您也可以使用 Azure Pipelines,在雲端和內部部署中將程式碼部署到 Azure 服務、虛擬機器以及其他目標。

管線的輸入 (我們的程式碼或設定) 位於版本控制系統中 (例如 GitHub 或另一個 Git 提供者)。

Azure Pipelines 會執行於計算元件上 (例如虛擬機器或容器),提供執行 Windows、Linux 和 macOS 的組建代理程式, 其也能將測試、安全性和程式碼品質外掛程式整合在一起。最後,這項工具可輕鬆擴充,因此可將自己的自動化帶入 Azure Pipelines。

管線會使用 YAML 語法或透過 Azure 入口網站中的傳統使用者介面來定義。 當使用 YAML 檔案時,可將該檔案連同程式碼一起儲存。 管線也提供可用來輕鬆建立管線的範本;例如,建置 Docker 映像或 Node.js 專案的管線。 您也可以重複使用現有的 YAML 檔案。

無論使用的是 YAML 檔案或傳統介面,請參閱下列基本步驟:

  1. 設定 Azure Pipelines 以使用 Git 存放庫。
  2. 編輯 azure-pipelines.yml 檔案或使用傳統編輯器來定義組建。
  3. 將程式碼推送至版本控制存放庫。 此動作會觸發管線來建置並測試程式碼。

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

有些功能 (例如執行中的容器作業) 只有在使用 YAML 時才可使用,其他功能 (例如工作群組) 則僅適用於傳統介面。

Azure Pipelines 建構

管線的結構如下:

  • 作業: 作業是在單一組建代理程式上執行的一組工作或步驟。 作業 (job) 是可供排程執行的最小工作 (work) 元件。 作業中的所有步驟會依序執行。 這些步驟可以是任何所要的動作類型,包括建置/編譯軟體、準備用於測試的範例資料、執行特定的測試等。

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

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

管線可根據需要變得簡單或複雜。 針對管線結構提供卓越的教學課程,這些教學課程也適用於 [透過 Azure DevOps 來建置應用程式] 的學習路徑。

環境可追蹤性

管線還有另外一個層面,也就是值得一提的可靠性。 您可以用這種方式來建立管線,以將生產環境中執行的內容與特定的建置執行個體相互關聯。 在理想的情況下,應該能夠追蹤組建到特定的 PR 或程式碼變更。 當嘗試找出導致問題的變更時,無論是在事件發生期間,還是事件發生後的檢閱,這都非常有幫助。 有些 CI/CD 系統 (例如 Azure Pipelines) 可供輕鬆地執行此動作,有些則需要手動建立管線,以在所有階段中傳播某種「組建識別碼」。

檢定您的知識

1.

認可、測試、掃描和建置是下列哪一項的一般步驟?

2.

環境可追蹤性可供執行下列哪一項作業?