本文說明如何運用Google Kubernetes Engine，在多團隊軟體交付平台實作新式持續整合/持續推送軟體更新 (CI/CD) 程序。
接著，您可以反覆調整平台，進一步提升開發和營運效能，包括發布速度、平台可靠性，以及從故障中復原的時間。
本文件是系列文章之一：
使用 GKE 進行現代化的持續整合/持續推送軟體更新：軟體推送架構 (本文件)
本文的目標讀者為企業架構師和應用程式開發人員，以及 IT 安全性、開發運作和網站穩定性工程團隊。如要瞭解本文中的概念，建議您先累積一些自動化部署工具和程序的經驗。
現代化 CI/CD 的案例
CI/CD 是一種軟體開發方法，可讓您使用多種工具和可重複的程序，自動執行軟體開發的建構、測試和部署階段。
除了 CI/CD 自動化，Kubernetes 和容器也協助企業大幅提升開發和部署速度。然而，即使 Kubernetes 和容器的採用率不斷提高，許多機構仍無法充分發揮發布速度、穩定性和作業效率方面的優勢，因為他們的 CI/CD 做法並未充分運用 Kubernetes，也未解決作業和安全性方面的疑慮。
真正的現代化 CI/CD 方法不僅要自動化，如要充分提升速度和安全性，並運用 Kubernetes 和容器的強大功能，您必須簡化應用程式上線、持續整合/持續推送軟體更新做法和作業程序。
透過 GKE 平台提供的一致基礎架構、統一的 CI/CD 方法，以及實作最佳做法，貴機構可獲得下列開發和營運優勢：
縮短變更的前置時間。
讓營運和安全團隊在整個平台中，建立及更新應用程式佈建和佈建政策的最佳做法。
提供功能齊全且可部署的入門專案，內建貴機構的最佳做法，簡化應用程式的導入程序。
縮短還原服務所需時間。
使用 GitOps 以宣告方式管理所有設定，簡化稽核、復原和審查程序。
在整個機構中，標準化部署和監控方法，縮短找出服務影響問題相關因素的時間。
提高部署頻率。
確保應用程式開發人員可以在自己的開發沙箱 (或登陸區) 中獨立疊代，不會互相干擾。
使用 GitOps 進行部署、改善版本管理，以及追蹤變更。
實施防護機制，讓服務團隊有能力頻繁部署。
建立漸進式推出程序，在預先發布環境中持續部署，讓開發人員有信心將變更部署至正式環境。
如要瞭解如何透過 GKE 和 CI/CD 實現這些優勢和概念，請參閱本系列的其他文件：
評估是否已準備好採用現代化方法
使用 GKE 導入新式 CI/CD 工具和程序前，請先評估貴機構和團隊是否已準備好採用新平台。
組織特徵
採用現代化平台時，您需要業務領導團隊和技術團隊提供下列支援：
領導贊助者：採用軟體交付平台通常需要多個跨職能團隊投入大量心力。這個程序通常會導致角色和職責，以及軟體開發實務發生變化。如要成功採用這些工具和技術，您需要領導團隊中至少一位成員的大力支持。最有效的領導贊助者會將這些變更視為持續改善的過程，並希望授權給團隊，而非管理團隊。
技術和業務策略一致。建議貴機構的業務團隊和技術團隊，根據 DevOps Research and Assessment (DORA) 定義的四項軟體交付關鍵指標，達成共識：變更的前置時間、部署頻率、還原服務所需時間，以及變更失敗率。業務團隊和技術團隊可根據這些指標設定共同目標，一起計算投資報酬率、調整變化率，以及修改投資金額。
資源。如要成功開發現代 CI/CD 做法及建構工具鍊，團隊必須具備必要資源：時間、人力和基礎架構。這些團隊需要時間嘗試並選出最佳程序和工具。理想情況下，這些團隊代表軟體交付程序中的許多不同功能，並可從整個機構中提取其他資源。最後，團隊需要佈建基礎架構，包括雲端資源和軟體工具。
願意採用新工具。現代 CI/CD 工具和技術通常會搭配新工具和程序。團隊需要實驗這些程序和工具，並願意採用。平台團隊需要意見回饋迴路，才能聽取使用該平台的應用程式、營運和安全團隊的意見。
文化適應性。如要在 GKE 中成功部署及採用現代化 CI/CD 系統，機構和開發該系統的技術團隊必須準備好改變運作和協作方式。舉例來說，開發和營運團隊必須願意承擔更多安全責任，而安全和營運團隊則必須願意簡化變更核准程序。
技術功能
採用現代化 CI/CD 方法時，團隊也必須在技術上做好下列準備：
容器使用經驗。採用現代 CI/CD 方法的團隊需要具備容器相關經驗。理想上，這項體驗應包含建構容器映像檔的開發技術，以及結合容器來建構大型系統。
持續整合策略。團隊需要具備使用 CI 工具 (例如 Jenkins、TeamCity、Bamboo 和 CircleCI) 的經驗，並執行一些持續整合和自動化測試。建議機構規劃如何進一步強化這些程序。
部署自動化。團隊需要具備部署自動化經驗。自動部署工具的例子包括基本 Shell 指令碼、Terraform、Chef 或 Puppet。具備自動部署工具和程序的基礎知識，是簡化及自動化部署作業的關鍵。
服務導向架構。雖然採用更現代化的 CI/CD 流程並非必要條件，但對於想在 GKE 中採用現代化 CI/CD 工具和技術的機構來說，採用更模組化且以服務為導向的架構，是長期目標。服務架構可提高速度和可靠性。
現代化來源控管。Git 等現代原始碼控管工具可讓團隊建立工作流程，例如以主幹為基礎的開發、功能分支和合併要求。
使用 GKE 設計現代化的 CI/CD
本節說明軟體交付平台及其元件。如要提升軟體交付成效，您需要導入 CI/CD 和其他技術最佳做法，讓團隊快速發布軟體並有效率地運作。
本節也會討論支援軟體交付生命週期所需的基礎架構，以及如何使用 GKE 持續管理該基礎架構。最後，本節提供軟體交付工作流程範例，並說明入門儲存庫如何簡化最佳做法的導入和實作程序。以下是審查的設計考量：
軟體推送平台。這個架構和技術功能是高速度、可靠應用程式發布流程的基礎。
平台基礎架構。建構平台及執行應用程式所需的基礎架構元件和管理考量。
軟體交付工作流程。瞭解團隊如何攜手合作，更有效率地建構、測試及部署程式碼。
程式碼存放區。存放區可執行多項功能，包括儲存實際的商業邏輯、應用程式專屬設定，以及建構基礎架構的程式碼。這些也可以是入門存放區，有助於採用最佳做法，並在自動化程序中維持一致性。
應用程式登陸區。邏輯實體，可讓開發人員使用您設定的防護措施，自主部署及疊代應用程式。
營運模式。管理平台基礎架構和應用程式的技術工具、程序和方法。
管理。您需要維護及管理軟體推送平台，因此請考量以下程序和注意事項。
軟體推送平台
軟體交付平台整合了建構、交付、部署及營運應用程式所需的工具，並簡化相關程序。
維護應用程式設定、穩定性、正常運作時間和規模的責任，會因營運人員、安全性和開發人員團隊而異，但所有元件和團隊都需要共同合作，才能加快發布速度。本文說明如何改善原始碼控管管理和應用程式可觀測性，但主要著重於持續整合 (CI)、持續推送軟體更新 (CD) 和設定管理。
如要建構完整的軟體交付平台，您需要下列圖表中的每個元件：
這些元件各自為平台上的系統和應用程式提供功能：
基礎架構監控。在佈建時，需要進行基本層級的監控，以驗證 Google Kubernetes Engine (GKE) 叢集、虛擬機器 (VM) 執行個體，以及應用程式運作所需的其他基礎架構是否正常運作。
容器自動化調度管理。這個平台可協調容器型應用程式的部署和運作。容器自動化調度管理平台範例包括 Kubernetes、GKE 或 GKE Enterprise。
容器登錄檔。容器映像檔的儲存空間和存取權控管。
CI. 在部署應用程式前，將自動化工作套用至應用程式的程序。CI 工作通常包括建構、封裝和測試。工作類型會因應用程式和機構而異。
CD。高度自動化且頻繁執行的部署程序。例如手動核准、初期測試部署、藍綠部署或滾動部署。
政策。營運和安全團隊定義的安全性和基礎架構設定政策，平台會持續套用及強制執行。
原始碼管理。舉例來說，程式碼、設定檔和政策定義的版本管控儲存空間。在現代 CI/CD 系統中，原始碼管理通常是 Git。
設定管理。用於儲存及套用不同環境的應用程式設定。
應用程式觀測能力。開發人員、營運人員和安全團隊用來排解問題及驗證應用程式是否正常運作的應用程式層級記錄、監控、警報和追蹤功能。
平台基礎架構
如要建構可擴充的軟體交付平台，您需要 Kubernetes 叢集，用於開發、試產環境和多個正式環境叢集。叢集可執行許多不同功能：
開發。在這些叢集中，開發人員會臨時部署應用程式，以進行測試和實驗。
應用程式環境。
前製階段。在工作流程中，您應為每個前置製作環境準備 Kubernetes 叢集，以代管應用程式。這些叢集應與正式版叢集相似，這樣您就能減少或消除環境之間的差異，進而提高部署成功率。
正式版：這些叢集會執行實際工作環境工作負載。 您應該使用多個地理位置分散的叢集。這麼做可提升基礎架構故障的可靠性，並減輕第 2 天作業的疑慮，例如叢集升級和擴充。
下圖顯示高階架構：
在這個架構中，您會透過 Config Sync 管理各個環境的叢集。一致的叢集設定至關重要，因為這能讓開發人員、營運人員和安全團隊確信，預先發布和正式環境的運作方式類似。您可以使用 Config Sync，在叢集機群中儲存及套用通用設定。叢集設定標準化、可稽核及可擴充後，您就能專注於軟體交付工作流程，以及導入和部署應用程式。
您可透過應用程式的 CI/CD 管道，管理開發、測試和正式叢集的部署作業。原始碼控管管理系統是應用程式程式碼和設定的協調點。應用程式的 CI/CD 管道和容器映像檔會與該應用程式的環境隔離。您可以使用啟動程式庫和自動化工具，初始化應用程式和設定存放區。舉例來說，您可以使用 Cloud Build 執行 Terraform，自動導入及初始化新應用程式。
您可以在每個叢集上，將應用程式部署到各自的登陸區，確保應用程式在網路和身分方面相互隔離。您可以使用 Config Sync，在各個環境中初始化應用程式登陸區，並使用 Cloud Service Mesh 或 Multi Cluster Ingress，建立跨越多個叢集的網路網格，讓生產環境叢集看起來像是一個叢集。
軟體推送工作流程
軟體交付平台的核心元件是 CI/CD 系統。平台建構人員開始定義 CI/CD 程序時，必須確保每個元件都會產生或消耗符合標準介面的構件。使用標準化介面可簡化元件更換程序，以便在市場上推出更優質的實作方式時，輕鬆進行更換。
建立容器化應用程式的平台時，您可以使用元件之間的三個標準化介面：Git 存放區、Docker 映像檔和 Kubernetes 資訊清單。這些介面可讓您建立可重複使用的彈性 CI/CD 管道，並搭配開發、建構及發布工作流程，如下圖所示：
這個工作流程的運作方式如下：
開發人員將應用程式程式碼提交至程式碼存放區。
CI 系統會測試程式碼、建立 Docker 映像檔構件，並將構件儲存在登錄檔中。
當構件準備好部署時，系統會將構件的參照新增至應用程式設定。
應用程式設定會以 Kubernetes 可讀取的格式呈現，並儲存在程式碼存放區。更新這個存放區會觸發部署管道，在整合式開發環境中部署構件。
在整合式開發環境中完成測試後，作業人員會將部署作業升級至前置生產環境。
確認應用程式在預先發布環境中正常運作後，營運人員會在部署管道中取得核准，並將版本升級至實際工作環境。
如果電信業者變更基本設定，這些變更會套用至整個機構。當運算子將變更提交至存放區時，系統會自動觸發應用程式設定更新 (以及後續部署作業)。或者，開發人員下次部署變更時，可以一併採用營運人員的變更。
同時，安全工程師可以實作及調整政策，定義可部署的內容，然後將這些政策提交至政策存放區。
使用 GitOps 方法時，您可針對應用程式和叢集的任何變更，要求採用宣告式方法。採用這種做法時，所有變更都必須經過稽核和審查，才能強制執行。在這個宣告式模型中，您會將設定檔儲存在 Git 存放區，以便維護變更記錄、復原失敗的部署作業，以及查看提議變更的潛在影響。
在相關的參考架構中，您可以使用 kustomize 控制貴機構的應用程式設定。營運人員可使用 kustomize 工具建立所謂的應用程式設定基礎，開發團隊可調整這些設定，不必在基礎中新增或變更任何程式碼。平台團隊可以定義基本設定，為機構建立及疊代最佳做法。作業人員和開發人員可以各自疊代部署作業，開發人員則可套用作業人員設定的最佳做法。如果營運人員需要為機構導入新的最佳做法，他們會在基礎中進行變更，而開發人員下次部署時，系統就會自動提取變更。
程式碼存放區
原始碼存放區是 CI/CD 系統的核心。操作人員、開發人員和安全工程師各有自己的存放區，可將變更傳播到平台。以 Git 存放區做為系統中所有變更的基礎，可帶來多項優點：
內建稽核功能。提交內容包含系統變更的時間、內容和人員等資訊。
簡化的復原程序。Git 的還原功能可讓您回溯至系統的先前狀態。
版本管理。您可以標記 Git 提交，表示系統狀態的版本。
交易。您必須明確解決狀態衝突並檢查，才能將變更整合至狀態。
下圖顯示各團隊如何與集中式存放區互動，以進行所有變更：
以下各節說明在現代 CI/CD 系統中，運算子、開發人員和安全工程師如何使用 Git 存放區。
運算子存放區
由運算子管理的存放區包含 CI/CD 和應用程式設定的最佳做法，可協助團隊導入應用程式，同時從一開始就採用機構的最佳做法。由營運人員管理存放區，開發人員就能盡可能減少工作流程中斷的情況，隨時掌握機構最佳做法的最新動態。
營運商可將機構的最佳做法編碼至兩個存放區。 第一個存放區是運算子維護共用 CI/CD 管道最佳做法的地方。在這個存放區中，運算符會為開發人員提供預先定義的工作程式庫，可用於建構管道。開發人員的應用程式存放區會自動繼承這些工作和其中的邏輯，不必手動複製工作。以下列舉幾個可在機構內標準化的工作：
建構及儲存構件
各種語言的測試方法
部署步驟
政策檢查
安全性掃描
營運人員維護的第二個存放區，會儲存設定應用程式的最佳做法。就 GKE 而言，最佳做法是確保有方法可在 Kubernetes 資源模型中管理宣告式資訊清單。這些資訊清單會說明應用程式的預期狀態。營運商可以為不同類型的應用程式建立基本設定，為開發人員提供簡化的路徑，以便根據機構的最佳做法部署應用程式。
應用程式存放區
應用程式存放區會儲存應用程式的商業邏輯，以及應用程式正常運作所需的任何專用設定。
營運人員以編碼方式建立及維護最佳做法時，開發人員就能使用這些最佳做法。為此，開發人員會參考 CI/CD 的工作，以及運算子在自己的存放區中建立的應用程式基礎。開發人員完成變更後，營運人員可以進一步自訂應用程式的部署作業，例如新增環境專屬的設定，像是資料庫網址或資源標籤和註解。
您可以在應用程式存放區中儲存下列構件：
應用程式原始碼
Dockerfile，說明如何建構及執行應用程式CI/CD 管道定義
擴充或修改運算子建立的應用程式設定基礎
基礎架構即程式碼存放區
基礎架構即程式碼存放區會儲存程式碼，用於建構執行應用程式所需的基礎架構。基礎架構可能包括網路和容器自動化調度管理平台，例如 GKE。基礎架構管理員通常擁有這些存放區。營運商可以更新這些設定，導入最佳做法。
您可以在應用程式存放區中儲存下列構件：
- 代表基礎架構物件的陳述式語言程式碼 (Terraform、Pulumi)。
補充宣告式 API 定義的 Shell 或 Python 指令碼。
基礎架構團隊建立的基礎架構範本擴充功能或修改項目。
設定和政策存放區
確保平台安全無虞且一致，是營運人員和安全工程師的首要之務。
設定
集中式設定可讓您在整個系統中傳播設定變更。您可以集中管理下列常見設定項目：
Kubernetes 命名空間
配額
角色型存取權控管 (RBAC)
網路政策
您應在整個叢集中持續強制執行這類設定，以免應用程式團隊誤用或濫用基礎架構。使用 Git 存放區儲存設定，可透過 GitOps 等方法稽核及部署設定，進而提升相關程序。Config Sync 等工具可簡化在基礎架構中統一套用設定的程序。
政策
由於開發人員可以擴充運算子建立的基本設定，因此您需要限制在組成平台的叢集中建立的資源。在某些情況下，您可能會建立政策，允許開發人員建立資源，但這些資源必須符合特定需求，例如建立無法設定外部負載平衡的 Kubernetes Service 物件。
在相關的參考架構中，您可以使用 Policy Controller 強制執行政策。
入門存放區
入門存放區有助於在整個平台採用 CI/CD、基礎架構和開發最佳做法。入門存放區可大幅降低採用最佳做法的相關成本。這些最佳做法可提高功能開發速度、可靠性和團隊生產力。在相關的參考架構中，有適用於 CI、CD、Kubernetes 設定、Go、Java 和 Python 啟動應用程式與基礎架構的多個啟動儲存庫。
持續整合
機構通常會有一組標準工作，在 CI 期間套用至應用程式。舉例來說，在參考實作項目中，CI 階段的基本組合如下：編譯程式碼，以及建構容器映像檔。由於這些階段是在入門儲存庫中定義，因此會統一套用至整個平台。個別應用程式團隊可以新增其他步驟。
持續推送軟體更新
與 CI 類似，CD 的程序通常有一組標準步驟，可透過開發、試產和實際工作環境部署應用程式。無論採用哪種部署方法，平台團隊都能透過入門存放區，在應用程式和環境中統一套用這些方法。在參考實作中，部署程序包括開發、前製部署的推出作業、跨多個叢集的正式環境部署，以及使用 Cloud Deploy 手動核准正式環境部署。
應用程式設定
如要有效運用軟體交付平台，您需要以一致的方式套用應用程式設定。使用 kustomize 等工具和 Kubernetes 設定的入門存放區，平台可為應用程式設定提供一致的基礎。舉例來說，在參考實作中， kustomize 基本設定會使用一組已知良好的基本設定，初始化應用程式環境存放區。個別應用程式團隊隨後可根據自身需求調整設定。
入門應用程式
入門應用程式可協助您減少採用最佳做法 (例如可觀測性和容器最佳做法) 相關的負擔。
可觀測性。為有效運作應用程式並確保可靠性，應用程式必須考量記錄、指標和追蹤。入門應用程式可協助團隊在架構和策略中建構觀測功能。
容器最佳做法。建構容器化應用程式時，請建構小型且乾淨的容器映像檔。容器最佳做法包括在映像檔中封裝單一應用程式、從映像檔中移除不必要的工具，以及積極嘗試從最小的基本映像檔產生小型映像檔。
參考架構提供基本 Go 應用程式、基本 Java 應用程式和基本 Python 應用程式，做為起點。您應新增為團隊開發的語言、技術堆疊和應用程式類型量身打造的入門應用程式。
基礎架構入門存放區
基礎架構入門存放區隨附建立不同基礎架構元件所需的預先編寫程式碼。這些存放區會使用基礎架構團隊決定的標準範本和模組。
舉例來說，在參考實作中，platform-template 包含用於建構專案、虛擬私有雲和 GKE 叢集的範例程式碼。 Google Cloud 基礎架構團隊通常會使用這個範本，以共用資源的形式，管理多個應用程式團隊使用的基礎架構。同樣地，infra-template 包含應用程式可能需要的基礎入門基礎架構程式碼，例如 Cloud Storage 或 Spanner 資料庫。應用程式團隊通常會使用這個範本，管理應用程式的基礎架構。
共用範本存放區
共用範本存放區提供標準工作範本，貴機構的任何使用者都能重複使用。舉例來說，基礎架構即程式碼模組 (例如 Terraform 模組) 可用於建立網路和運算等基礎架構資源。
應用程式登陸區
使用共用的 CI/CD、共用的應用程式設定，以及叢集間一致的政策和設定，就能將這些功能綁在一起，建立應用程式登陸區。
登陸區是鎖定的邏輯實體，可供開發人員部署及疊代應用程式。應用程式登陸區會使用您設定的防護措施，讓開發人員能夠自主運作。針對每個應用程式，您會在每個環境的每個叢集中建立 Kubernetes 命名空間 (例如用於正式版、開發或測試環境)。這種一致性有助於運算子長期偵錯及維護環境。
下圖說明登陸區的概念：
作業模式
使用現代化 CI/CD 運作軟體交付平台時，請務必確保環境、基礎架構和程序一致且為最新狀態。因此，您需要仔細規劃並選擇平台的營運模式。您可以選擇各種模型，例如叢集即服務、藍圖或多租戶基礎架構。
為了維持基礎架構的一致性、限制蔓延，並讓團隊專注於交付應用程式，我們建議您部署多租戶基礎架構。在多租戶基礎架構上部署應用程式後，應用程式團隊就不必管理基礎架構，營運和安全團隊則可專注於維持基礎架構的一致性。
多租戶基礎架構的注意事項
建構多租戶軟體交付平台時，可以考慮在平台中加入下列功能：
工作負載隔離。應用程式登陸區的概念是提供工作負載隔離架構。登陸區是命名空間、網路政策和 RBAC 的組合。所有這些政策都應透過 Config Sync 集中管理及套用。
監控租戶用量。如要取得叢集中個別命名空間和標籤的費用明細，可以使用 GKE 用量計算功能。GKE 用量計算功能會追蹤叢集工作負載的資源要求和資源用量資訊，您還可以依命名空間和標籤進一步篩選。在多租戶叢集上啟用 GKE 用量計算功能後，資源用量記錄會寫入 BigQuery 資料表。您可以將特定租戶的指標匯出至對應租戶專案中的 BigQuery 資料集，稽核人員隨後就能分析這些指標，判斷費用明細。
資源配額。為確保共用叢集的所有用戶群都能存取叢集資源，您需要強制執行資源配額。根據每個租戶部署的 Pod 數量，以及每個 Pod 需要的記憶體和 CPU 數量，為每個命名空間建立資源配額。
每個環境有多個叢集。為提升應用程式和平台穩定性，您應為每個預先發布和實際執行環境使用多個叢集。有了多個叢集，您就能將應用程式個別推出至叢集，進行額外的 Canary 驗證。此外，多個叢集可減輕與叢集管理和升級生命週期相關的疑慮。
租戶專屬的記錄與監控功能：如要調查應用程式的運作情形，租戶需要存取記錄和指標。在多租戶環境中，記錄和監控功能應專用於應用程式。如要查看指標和監控，您可以為每個命名空間使用 Google Cloud Managed Service for Prometheus 和 Grafana。如要匯出記錄檔項目至 BigQuery 資料集，您需要建立接收器，然後依房客命名空間篩選資料集。租戶隨後就能在 BigQuery 中存取匯出的資料。
如要進一步瞭解多租戶基礎架構，請參閱「企業多用戶群的最佳做法」。
隔離界線
多個團隊會建構及使用軟體交付平台，因此平台不同元件之間必須有適當的隔離界線。隔離界線提供下列特徵，有助於建構穩固的平台：
責任分離。每個團隊都會管理隔離界線內的資源，不必擔心其他資源。舉例來說，基礎架構團隊只負責維護 GKE 叢集，運算子或開發人員只需負責維護 CI/CD pipeline 和應用程式程式碼。
精細的存取權控管機制。如果資源是依據隔離界線區隔，請使用精細的存取權控管機制來限制存取權。
減少受影響的區域。您可以獨立變更元件，不會影響其他元件。
減少人為錯誤。由於存取控管非常精細，您可以避免手動錯誤，例如不小心從開發環境部署到生產環境叢集。
這些隔離界線可能存在於不同應用程式、基礎架構和應用程式之間，甚至是應用程式的不同環境之間。
管理
軟體推送平台和現代 CI/CD 系統的主要目標，是提高整體軟體推送程序的效率。就平台管理而言，您有兩個主要考量點：應用程式上線 (通常屬於控管類別)，以及平台的持續開發和維護 (也就是將平台視為產品)。
應用程式上線和管理
採用現代 CI/CD 方法和工具的目標，是簡化發布程序和新服務的導入程序。導入新應用程式的程序應簡單明瞭，您只需投入最少的心力，即可完成作業和安全團隊的工作。這並非表示營運和安全團隊不會參與，而是指從部署和安全角度來看，他們最初的輸入內容會透過佈建程序自動處理。加入後，營運和安全團隊自然會透過合併要求、政策更新和最佳做法強制執行，參與發布程序。
建議您建立一些自動化動作，協助新應用程式順利上線。這可能包括建立程式碼存放區、CI/CD 管道、登陸區，以及應用程式所需的任何基礎架構。自動化可讓開發團隊擺脫對機構內其他團隊的複雜依附關係，並讓開發人員自主服務應用程式。這樣一來，開發人員就能快速開始疊代應用程式的程式碼，不必浪費時間執行編寫程式碼以外的工作。自動化程序應讓開發人員在開發環境中執行應用程式。如要將應用程式移至較高環境，請讓其他團隊參與，並遵循審查程序。
在相關聯的參考架構中，這項自動化程序稱為「應用程式工廠」。
將平台視為產品
CI/CD 工作流程是軟體產品，但產品使用者是開發、營運和安全團隊。因此，這個平台需要相同的軟體開發角色和程序，例如產品負責人、行銷 (雖然是內部行銷)、使用者意見回饋迴路和功能開發週期。
使用 GKE 部署 CI/CD
開始使用 GKE 為機構部署現代化 CI/CD 時，選擇最佳的試用應用程式至關重要。開發、作業和安全團隊在工作時也需要考量其他因素，本節將討論這些因素。
選取前測申請
選擇要先遷移至平台的應用程式，可能是困難的第一步。適合試用計畫的服務包括處理資料或處理要求，但不儲存資料的服務，例如快取層、網站前端或以事件為基礎的處理應用程式。通常，這類應用程式較能承受少量停機時間，以及使用新部署和設定管理技術時可能發生的部署錯誤。隨著團隊在 CI/CD 方面累積更多經驗，並開始體驗可靠性和速度方面的優勢，您可以開始將核心服務移至軟體交付平台。
開發人員注意事項
在現代 CI/CD 開發程序中，功能、變更和部署作業的發生頻率會提高，且更具非同步性。開發團隊需要瞭解變更對下游或相依系統的影響，以及如何測試這些變更。開發、營運和安全團隊之間的溝通管道必須暢通無阻。建議您投入資源，為應用程式和不同服務間的資料合約採用更完善的版本控管做法。除了改善通訊方法和版本控管，以小塊實作功能，並運用功能分支和旗標，也能提升功能測試和發布的效率。
電信業者注意事項
有了軟體交付平台，營運團隊就必須更像開發團隊。他們不會建構對外功能，而是建構內部工具和程序，協助開發、部署及運作對外應用程式。平台工具由自家團隊以及開發和安全團隊使用。運算子應建構工具，協助推出新版應用程式，並在應用程式發生錯誤或部署失敗時還原。營運商也應更加重視建構監控和快訊系統，主動偵測故障並相應發出快訊。
安全團隊考量
安全團隊應努力讓安全成為自己與營運和開發團隊之間的共同責任。這種模式通常稱為「向左移動」安全防護，也就是在開發流程初期就納入資訊安全 (InfoSec) 考量，開發人員使用預先核准的工具，並自動進行安全測試。除了上述技術外，您也可以透過政策控制器，以程式輔助方式定義及強制執行安全性政策。結合這些技術和工具，可讓安全防護措施更加主動。
後續步驟
進一步瞭解設定身分聯盟的最佳做法。
請參閱「Kubernetes and the challenges of continuous software delivery」。
閱讀有關混合雲和多雲端監控及記錄模式的文章。