這份指南介紹一系列最佳做法，協助您向 Google Kubernetes Engine (GKE) 進行持續整合與持續推送軟體更新 (CI/CD)。這些做法涵蓋多個主題，從原始碼控管到部署策略都會探討。這些最佳做法專為 GKE 而設計，一般 CI/CD 最佳做法仍適用。詳情請參閱「開發運作技術：持續整合」和「開發運作技術：持續推送軟體更新」。
持續整合
持續整合 (CI) 是一種做法，開發人員會盡可能經常將所有程式碼變更整合回主要分支。目的是盡早發現問題，以便快速失敗。通常，開發人員推送程式碼變更時，就會觸發 CI 管道。管道包含驗證這些變更的步驟，例如檢查、測試及建構。CI 管道通常會產生可在部署程序後續階段部署的構件。
建立可快速疊代的管道
開發人員進行程式碼變更後，您應盡快取得應用程式的執行版本。在功能分支上開發時，開發人員會快速疊代，因此速度特別重要。理想情況下，CI 管道應在 10 分鐘內執行完畢。如果無法這樣做，請建立下列兩種 CI 管道：
快速管道：這類管道通常會在 10 分鐘內執行完畢。 這些管道適用於功能分支，並非全面性管道。 快速管道可能會導致構件不穩定。
完整管道：這些管道的執行時間可能超過 10 分鐘，且會執行更全面的測試和檢查。完整管道會在合併或提取要求，以及提交至主要分支版本時執行。
測試容器映像檔
在持續整合管道中，請務必對程式碼和建構構件執行所有必要測試。這些測試應包括單元、功能、整合，以及負載或效能測試。
測試建構的容器映像檔結構也很重要。 測試結構可確保所有指令都能在容器內如預期執行。測試時，您也可以檢查特定檔案是否位於正確位置，以及內容是否正確。
如要測試容器映像檔，可以使用容器結構測試架構。
在管道早期建立安全性
在開發生命週期中盡早進行安全檢查和平衡。在建構構件或部署前找出安全風險，可減少處理這些風險所花費的時間和成本。
為協助及早偵測，您可以在管道中實作下列安全措施：
要求主題專家審查整合至正式版存放區的任何程式碼。
在管道早期導入 Linting 和靜態程式碼分析。這項測試有助於找出弱點，例如未逸出輸入內容、接受 SQL 查詢的原始輸入資料，或程式碼中的安全漏洞。
使用安全漏洞掃描功能，掃描建構的容器映像檔是否有安全漏洞。
使用二進位授權，防止含有安全漏洞的映像檔部署至叢集。二進位授權需要GKE Enterprise 訂閱方案。為確保生成的圖片品質，二進位授權也允許您要求不同實體或系統提供認證。例如，這些認證可能包括：
- 通過安全漏洞掃描
- 通過品質確保測試
- 產品負責人簽核
持續推送軟體更新
持續推送軟體更新 (CD) 可讓您隨時發布程式碼。CD 會處理 CI 管線產生的構件。CD 管道的執行時間可能比 CI 管道長得多，尤其是在使用更精細的部署策略 (例如藍綠部署) 時。
使用 GitOps 方法
GitOps 的概念是將宣告式基礎架構儲存在 Git 存放區，並使用 CI/CD 工具將該基礎架構部署至您的環境。使用 GitOps 方法時，您可以確保應用程式和叢集的所有變更都儲存在來源存放區，且隨時可存取。
使用 GitOps 方法可帶來下列優點：
- 您可以透過合併或提取要求，在部署變更前先進行檢查。
- 您可以在單一位置隨時查看應用程式和叢集的狀態。
- 叢集和應用程式的快照可讓您在發生故障時，更輕鬆地復原。
如要進一步瞭解 GitOps 方法和可在來源存放區中使用的不同模式，請參閱 GitOps 概念。
用於陳述式基礎架構的常見工具包括 Hashicorp 的 Terraform，以及 Google Cloud的 Config Connector。如要實際練習使用 GitOps 和其他工具管理基礎架構，請參閱「使用 Terraform、Cloud Build 和 GitOps 管理基礎架構式程式碼」教學課程。如要瞭解如何以 GitOps 模式管理應用程式，請試試使用 Cloud Build 以 Git 運作方式持續推送軟體更新。
升級而非重建容器映像檔
容器映像檔不應在 CI/CD 管道的不同階段中重建。重建可能會導致程式碼分支出現微小差異。這些差異可能會導致應用程式在正式環境中失敗，或導致未經測試的程式碼意外新增至正式環境容器映像檔。為確保您測試的容器映像檔與部署的容器映像檔相同，建議您建構一次，然後在各個環境中升級。這項建議的前提是，您會將特定環境設定與套件分開。
考慮使用更進階的部署和測試模式
GKE 提供多種模式，讓您彈性部署及測試應用程式。您選擇的部署模式主要取決於業務目標。舉例來說，您可能需要部署變更，且不得有任何停機時間，或是在功能正式推出前，先將變更部署至環境或部分使用者。
您可以使用的部署模式包括：
重新建立部署作業：先完全縮減現有應用程式版本，再擴增新版應用程式。
滾動式更新部署作業：您會更新部分執行中的應用程式執行個體，而不是一次更新所有執行中的應用程式執行個體。然後逐步更新更多執行中的應用程式執行個體，直到全部更新完畢。
藍綠部署：您會將額外的平行執行個體集部署到現有的正式版執行個體，並使用升級版應用程式。準備好部署時，請將流量切換至新執行個體。
為不同環境建立獨立叢集
環境分離是任何部署目標的重要考量。理想情況下，您應該為下列每個環境分別建立叢集：
開發環境：開發人員會在這種環境中部署應用程式，以進行測試和實驗。這些部署作業需要與應用程式或系統的其他部分 (例如資料庫) 整合。這個環境的叢集通常閘道較少，開發人員對叢集設定的控制權也較大。
前置生產環境 (測試或品質保證)：這些環境應盡可能與生產環境相似。這些測試可用於大規模測試變更，例如整合、負載、效能或迴歸測試。
正式版環境：這個環境用於執行正式版工作負載，以及面向使用者的應用程式和服務。
如要進一步瞭解這些環境，請參閱 Kubernetes 中的環境和持續軟體交付的挑戰一文。
讓預先發布環境與正式環境保持一致
理想情況下，試產叢集與正式環境叢集完全相同，但為了節省成本，試產叢集可以縮減為副本。保持叢集相似可確保測試是在與正式環境相同或相似的條件下進行。預先發布和正式版叢集之間的同位性，也能降低因環境差異而導致非預期失敗的機率。
宣告式基礎架構和 GitOps 有助於讓環境更趨於一致，因為您可以更輕鬆地複製基礎叢集的設定。如要確保環境的政策和設定條件相似，您也可以使用 Config Sync 等工具。
為實際運作中的失敗做好準備
無論進行多少測試，都無法保證應用程式在正式環境中正常運作。失敗原因可能是資料的極端情況未納入考量，或是使用者存取模式未經過測試。請務必監控正式版應用程式，並建立自動回溯和部署機制，以便快速因應及修正錯誤或中斷問題。採用更完善的部署策略，可減少問題的影響，並在發生問題時，盡量避免影響到使用者。
檢查清單摘要
下表彙整了在 GKE 中使用 CI/CD 管道時，建議執行的工作：
| 區 | Tasks |
|---|---|
| 持續整合 |
|
| 持續推送軟體更新 |
|
後續步驟
- 瞭解企業多用戶群的最佳做法。
- 進一步瞭解 CI/CD on Google Cloud。