本文說明如何運用架構，在採用 Google Kubernetes Engine 的多團隊軟體交付平台，實作新式持續整合/持續推送軟體更新 (CI/CD) 程序。
接著，您可以反覆使用平台，進一步提升開發和營運的效能，包括發布速度、平台可靠性，以及故障後的復原時間。
本文件屬於下列系列：
透過 GKE 建立現代化 CI/CD：軟體推送架構 (本文件)
這份文件適用於企業架構師和應用程式開發人員，以及 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 或 多叢集 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 管道和應用程式程式碼。
精細的存取控管。如果資源是依據隔離界線區隔，請使用精細的存取控管機制來限制存取權。
減少受影響的區域。您可以獨立變更元件，不會影響其他元件。
減少手動錯誤。由於存取控管非常精細，您可以避免手動錯誤，例如不小心從開發環境部署到正式叢集。
這些隔離界線可能存在於不同應用程式、基礎架構和應用程式之間，甚至是應用程式的不同環境之間。
管理
軟體推送平台和現代 CI/CD 系統的主要目標，是提高整體軟體推送程序的效率。就平台管理而言，您有兩個主要考量點：應用程式上線 (通常屬於控管類別)，以及平台的持續開發和維護 (也就是將平台視為產品)。
應用程式上架與管理
採用現代 CI/CD 方法和工具的目標，是簡化發布程序和新服務的導入程序。導入新應用程式的程序應簡單明瞭，且您只需投入最少心力，即可完成作業，不必仰賴營運和安全團隊。這並非指營運和安全團隊不會參與，而是指佈建程序會自動處理他們從部署和安全角度提供的初步輸入內容。加入後，營運和安全團隊自然會透過合併要求、政策更新和最佳做法強制執行，納入發布程序。
建議您建立一些自動化動作，協助新應用程式順利上線。這可能包括建立程式碼存放區、CI/CD 管道、登陸區，以及應用程式所需的任何基礎架構。自動化作業可解除開發團隊對機構內其他團隊的複雜依附元件，並提供開發人員自主權，讓他們能自助式服務應用程式。開發人員可以快速開始疊代應用程式的程式碼，不必浪費時間執行編寫程式碼以外的工作。自動化程序應可讓開發人員在開發環境中執行應用程式。如要將應用程式移至較高的環境，請讓其他團隊參與，並遵循審查程序。
在相關的參考架構中，這項自動化程序稱為「應用程式工廠」。
以產品思維經營內部平台
CI/CD 工作流程是軟體產品，但產品使用者是開發、營運和安全團隊。因此，平台需要相同的軟體開發角色和程序，例如產品負責人、行銷 (雖然是內部行銷)、使用者意見回饋迴路，以及功能開發週期。
使用 GKE 部署 CI/CD
開始透過 GKE 為機構部署現代化 CI/CD 時，選擇最佳的試用應用程式至關重要。開發、營運和安全團隊在工作時也需要考慮其他因素，本節將討論這些因素。
選取前測申請
選擇要先移至平台的應用程式，可能是困難的第一步。適合試用計畫的服務包括處理資料或處理要求，但不儲存資料的服務，例如快取層、網站前端或以事件為基礎的處理應用程式。通常這類應用程式比較能承受少量停機時間，以及使用新部署和設定管理技術時可能發生的部署錯誤。隨著團隊在持續整合/持續推送軟體更新方面累積更多經驗，並開始體驗可靠性和速率方面的福利，您可以開始將核心服務移至軟體推送平台。
開發人員注意事項
在現代 CI/CD 開發程序中，功能、變更和部署作業的發生頻率會增加，而且會更加非同步。開發團隊需要瞭解變更對下游或相依系統的影響，以及如何測試這些變更。開發、營運和安全團隊之間的溝通管道必須暢通無阻。建議您投入資源，為應用程式和不同服務間的資料合約採用更完善的版本控管做法。除了改善通訊方法和版本管理，以小塊實作功能並運用功能分支版本和旗標，也能提升測試和發布功能的方式。
營運人員注意事項
有了軟體推送平台，營運團隊就必須更像開發團隊。他們不會建構對外功能，而是建構內部工具和程序，協助開發、部署及運作對外應用程式。平台工具由自家團隊以及開發和安全團隊使用。運算子應建構工具，協助推出新版應用程式，並在發生應用程式錯誤或部署失敗時，將應用程式復原至先前版本。營運商也應更加重視建構監控和警報系統，以便主動偵測故障並相應發出警報。
安全團隊考量
安全團隊應努力讓安全成為自己與營運和開發團隊的共同責任。這種模式通常稱為「安全左移」，也就是在開發流程初期就納入資訊安全 (InfoSec)，開發人員使用預先核准的工具，並自動進行安全性測試。除了上述技術外，您也可以使用 Policy Controller，以程式輔助方式定義及強制執行安全政策。結合這些技術和工具，可讓安全防護措施更具主動性。
後續步驟
進一步瞭解設定身分聯盟的最佳做法。
請參閱「Kubernetes and the challenges of continuous software delivery」(Kubernetes 與持續軟體發布的挑戰)。