隨著程式代碼的開發、更新或甚至移除，具有直覺且安全的方法，將這些變更整合到主要程式代碼分支中，可讓開發人員提供價值。
做為開發人員，您可以進行小的程式碼更改，將這些更改推送到程式碼儲存庫，並幾乎即時獲得有關品質、測試覆蓋率和引入的錯誤的意見反應。 這個過程可以讓您工作得更快、更有信心、風險更低。
持續整合 （CI） 是一種做法，原始檔控制系統和軟體部署管線會整合，以提供軟體開發小組的自動化建置、測試和意見反應機制。
當工程師建立 GitHub 拉取要求以向 CI 系統發出程式碼變更已準備好整合的訊號時，持續整合流程就開始了。 理想情況下，整合過程會根據多個基準和測試來驗證程式碼。 然後，它向提出要求的工程師提供有關這些測試狀態的意見反應。
如果基準檢查和測試順利進行，整合過程會產生資產，並分階段部署已更新的軟體。 這些資產包括編譯的程式碼和容器映像。
持續整合可以透過以下動作來幫助您更快地交付高品質的軟體：
- 針對程式碼執行自動化測試，以便儘早偵測到重大變更。
- 運行程式碼分析以確保程式碼標準、品質和配置。
- 執行合規性和安全性檢查，以確保軟體沒有已知的弱點。
- 執行驗收或功能測試以確保軟體能如預期運作。
- 對偵測到的問題提供快速意見反應。
- 在適用的情況下，產生包含更新程式碼的可部署資產或套件。
術語
在開始實施持續整合之前，先熟悉這些關鍵術語。
| 字詞 | Definition |
|---|---|
| 文物 | 建置過程中可部署的輸出，例如編譯後的程式碼、容器映像檔或部署套件。 |
| 自動化測試 | 一個自動執行的測試，作為 CI 流程的一部分，用以驗證程式碼品質並偵測問題，無需人工介入。 |
| 構建 | 這個程序負責編譯原始碼、執行測試，並產生部署所需的工件。 |
| 建置代理程式 | 一個自架或雲端託管的運算資源，負責在 CI 管線中執行任務與操作。 |
| 持續整合 （CI） | 一個整合原始碼控制系統與自動化管線的實務，以自動建置、測試及驗證程式碼變更。 |
| CI 管線 | 一個自動化工作流程，當開發者承諾使用原始碼控制時，會建置、測試並驗證程式碼變更。 |
| 整合測試 | 一種驗證不同元件或服務如何協同運作的測試，通常比單元測試更為全面。 |
| 夜間建設 | 一個定期（通常是夜間）執行的排程建置，用來執行較長時間的測試套件，例如整合測試和使用者介面測試。 |
| 提取要求 | 請求將程式碼的更改合併至另一分支。 觸發 CI 管線，在整合前驗證擬議變更。 |
| 發佈版本 | 這是一個包含編譯、測試、文件、合規報告與簽署的完整建置。 產出最終版本以供生產部署。 |
| 原始檔控制 | 一個能隨時間追蹤和管理程式碼變更的系統。 範例包括 Git、Azure Repos 和 GitHub。 |
| 狀態徽章 | 一個視覺化指示器（通常是圖片），顯示建置或測試的當前狀態，通常出現在倉庫文件中。 |
| 測試驅動開發（TDD） | 開發實務是開發者在撰寫符合測試的程式碼前先寫測試。 |
| 單元測試 | 一種測試，能單獨驗證各個功能或元件，以確保其行為符合預期。 |
自動化與管線的持續整合
若要實現持續整合，請使用軟體解決方案來管理、整合及自動化程式。 常見的做法是使用持續整合管線。
持續整合管線牽涉到一段軟體（通常裝載於雲端），可提供：
- 執行自動化測試的平臺。
- 合規性掃描。
- 報告。
- 構成持續整合程式的其他所有元件。
在大部分情況下，管線軟體會連結到版本控制系統，如此一來，當提出的拉取請求或軟體合併至特定分支時，就會執行持續整合管線。 原始碼控制整合還提供了直接針對拉取要求提供 CI 意見反應的機會。
許多解決方案 (例如 Azure Pipelines 或 GitHub Actions) 都會提供持續整合管道的功能。
整合管線與原始檔控制
將您的持續整合管道整合到您的原始碼控制系統中，對於實現快速而自主的程式碼貢獻至關重要。
CI 管道在新建立的拉取要求上運作。 該流程包括所有測試、安全評估和其他檢查。 CI 測試結果直接出現在拉取要求中，以實現幾乎即時的品質意見反應。
另一種流行的做法是建立可以在原始碼管理中呈現的小型報告或徽章，以使目前的建置狀態可見。
下圖顯示了 GitHub 和 Azure DevOps 管道之間的整合。 在此範例中，建立拉取請求會觸發 Azure DevOps 管線。 管道的狀態顯示在提取請求中。
納入自動化測試
持續整合的關鍵要素是在開發人員貢獻程式碼時持續建置和測試程式碼。 建立 Pull Request 時進行測試，可快速確認提交並未引入重大變更。 優點是持續整合管道中的測試可以與測試驅動開發期間運行的測試相同。
下列代碼段顯示來自 Azure DevOps 管線的測試步驟。 此步驟有兩個工作：
- 第一個工作會使用熱門的 Python 測試架構來執行 CI 測試。 這些測試會與 Python 程式代碼並存於原始檔控制中。 測試結果會移至名為 test-results.xml的檔案。
- 第二項工作會取用測試結果，並將其發佈至 Azure DevOps 管線作為整合報表。
- script: |
pip3 install pytest
pytest azure-vote/azure-vote/tests/ --junitxml=junit/test-results.xml
continueOnError: true
- task: PublishTestResults@2
displayName: 'Publish Test Results'
inputs:
testResultsFormat: 'JUnit'
testResultsFiles: '**/test-results.xml'
failTaskOnFailedTests: true
testRunTitle: 'Python $(python.version)'
下圖顯示出現在 Azure DevOps 入口網站中的測試結果。
失敗的測試
失敗的測試應該暫時阻止部署，並導致對發生的情況進行更深入的分析。 失敗的測試應該促使我們要麼細化測試，要麼改進導致測試失敗的變更。
發佈組建狀態
許多開發人員透過在其存放庫中顯示狀態徽章來顯示其程式代碼品質很高。 下圖顯示 GitHub 中開放原始碼專案的自述文件上顯示的 Azure Pipelines 徽章。
優化建置時間
若要執行更快速的組建，您可以：
選擇符合效能需求的代理程序：選取正確的組建機器來加速組建。 高速機械可以將工作時間從數小時縮短到數分鐘。 如果您的管線位於 Azure Pipelines 中，您可以使用Microsoft裝載的代理程式來執行作業。 當您使用Microsoft裝載的代理程式時，會為您處理維護和升級。 如需詳細資訊，請參閱 Microsoft 裝載的代理程式。
優化建置伺服器位置：當您建置程式代碼時，數據會透過網路傳送。 從原始碼控制庫和工件庫擷取建置所需的輸入。 必須複製建置程序的輸出，包括已編譯的成品、測試報告、程式代碼涵蓋範圍結果和偵錯符號。 請務必快速執行這些複製動作。 如果您使用自己的組建伺服器，請確定組建伺服器位於來源和目標位置附近。 快速上傳和下載可以減少整體建置時間。
向外延展組建伺服器：單一組建伺服器可能就足以用於小型產品。 隨著產品的大小和範圍和在產品上工作的小組數目增加，單一伺服器可能不夠。 當達到限制時，將基礎結構水平擴展於多台機器上。 如需詳細資訊，請參閱 建立和管理代理程式集區。
優化組建：
新增平行作業以加速建置程式。 如需詳細資訊，請參閱設定和支付平行作業的費用。
啟用平行測試套件執行，這通常會節省大量的時間，尤其是在執行整合和UI測試時。 如需詳細資訊，請參閱 針對任何測試執行器平行執行測試。
使用倍數的概念，您可以透過多個建置代理程式擴展建置。 如需詳細資訊，請參閱 在管線中指定作業。
考慮將整合、UI 和煙霧測試移至發行流水線。 移至發行管線可改善建置速度以及組建回應迴圈的速度。
將組建成品發佈至套件管理解決方案，例如 NuGet 或 Maven。 發佈至套件管理解決方案可讓您更輕鬆地重複使用組建成品。
實作組建類型以符合您的工作流程
您的組織可能會選擇建立數種不同類型的組建，以優化建置時間。 可能的組建包括：
持續整合 （CI） 組建：此組建的目的是確保編譯程式代碼並執行單元測試。 每次提交時，這個建置會被觸發。 它是專案的心跳，並立即向團隊提供高品質的回饋。 如需詳細資訊，請參閱 指定觸發管線的事件。
每夜建置：每夜建置的目的不僅是編譯代碼，還要確保所有較大且效率不佳的測試套件能定期在每次組建中執行。 這些測試通常包括整合、UI 或煙霧測試。 如需詳細資訊，請參閱 設定管線的排程。
發行組建：除了編譯和執行測試之外，此組建也會編譯 API 檔、合規性報告、程式代碼簽署，以及每次建置程式代碼時不需要的其他步驟。 此組建提供推送至發行管線的黃金複本，最終部署在生產環境中。
組織所需的組建類型取決於因素，包括小組和組織成熟度、您正在處理的產品種類，以及您的部署策略。
相關連結
瞭解如何使用 GitHub 或 Azure DevOps 建立持續整合管線：
瞭解如何在存放庫中顯示徽章：