1. 瞭解如何選取適當的 CI/CD 架構
  2. 找出最適合的架構或解決方案

找出最適合的架構或解決方案

請考量一系列的評估因素 (或應力因素)，以識別最符合您需求的參考架構 (RA) 或解決方案。下列區段提供您應考慮因素的相關資訊。

對於每個因素，我們將為您提供架構或解決方案是否支援因子的指示。必要時，您可以將每個係數指定為數值分數，讓其更加細微。請使用這些建議來使用資訊與決策矩陣。

  • 記錄哪個資料欄符合您的偏好答案。
  • 使用決策矩陣，根據每個評估因素比較最符合您需求的 RA 或解決方案。
  • 對比其他因素更重要的因素增加權重。

考慮各種評估因子

請考量每個評估因子，然後將其與每個架構和解決方案做比較，以判斷最適合您需求的因子。

容器、虛擬機器 (VM) 或專家

將流程部署至容器協調流程環境 (例如 Kubernetes) 內的容器，即可有效擴展資源，因應需要更多運算能力的流程。單位測試與靜態程式碼分析等作業有獲益的潛力。使用容器的下降部分是端對端組態中的複雜性增加。您的團隊必須瞭解如何使用容器協調工具，例如 Kubernetes。使用容器也可確保當容器損毀時，避免不小心取得暫時相依性或先前狀態資料。

使用 VM 較為簡單，因為您可以建置單一 VM 來處理管線的所有步驟。容器是單石性質。VM 方法也可以減少問題，例如允許開發人員代管，以及避免使用 Windows 與 Linux 主機的問題。

部分專家案例將僅支援 PaaS 或 SaaS 產品，其中建置程序會準備並部署服務的使用者自建物件。您可以使用一般用途工具來協調此作業。在某些情況下，使用特定必修課程的工具可能會較有助益。例如，Oracle Visual Builder Studio 專為與 Visual Builder 有關的解決方案而設計。

使用開源 / 第三方產品搭配 OCI 原生架構的管線協調

與使用 OCI Native 解決方案相比，使用網域特定或非常可自訂的工具 (包括開源工具，例如 Jenkins) 可在執行期間為組建處理作業提供更大的自由。雖然 OCI DevOps 等工具會定期發行新功能。但是，即使執行一般管線，這種靈活性也是管理更多流程階段 (例如部署、修補和監控) 的成本。

標準化部署儲存庫或特殊產品儲存庫

當您使用業界標準服務 (例如 OCI Git、GitLab 或 GitHub) 管理組態，以及類似工具時，原生服務將可支援您的需求。CI/CD 流程可能會受限於部分整合的舊有儲存區域。您可能需要對管線進行重大變更，才能將 CI/CD 處理作業與舊有儲存區域搭配使用。

業界標準組態管理或舊有工具

使用雲端提供的服務時，一般而言，服務僅支援使用組態管理 (CM) 系統 (例如 Git 和 SVN) 的業界標準解決方案。這些服務提供者也支援廠商自有產品所需的任何專家組態管理機制。如果您必須使用舊版或利基版 CM 系統，則可能需要考慮 CM 系統供應商所支援的第三方解決方案。例如，支援 CVS 作為舊有解決方案，使用者可能需要使用第三方工具來管理組態。

多重雲端或單一雲端部署

將相同的核心解決方案部署到多個雲端可以增加應考量的複雜性。例如，如果部署流程併入 Terraform 服務，則每個雲端提供者都需要有部署流程，以考量各種 Terraform 提供者的差異。需要更多細微考量 (例如 Docker 映像檔的目標晶片組)，因為建立不同的映像檔。

為了確保更好的安全性，您可以選擇不公開外部部署解決方案的部署目標。例如，如果您要部署到 Oracle Container Engine for Kubernetes (OKE) 和 Azure Kubernetes (AKE)，您可以使用 GitHub 來保存一般程式碼和 GitHub 動作來協調容器建置。但是，您可以選擇不要直接對 GitHub 動作顯示 AKS 和 OKE。請考慮使用 Azure 和 OCI 的多階段解決方案來提供部署協調，並使用 GitHub 來進行持續的組建處理作業或核心程式碼。

當「基礎架構即程式碼 (IaC)」是部署處理作業的一部分時，請考慮多階段解決方案。這讓每個環境擁有不同的 IaC 組態，可佈建運算、儲存及受管理的服務。使用 Kubernetes 可讓您限制或移除這類問題。

處理自訂或訂製處理

如果您需要特殊或利基的流程，支援組建管線的工具必須允許擴充自訂組態。建立您自己的訂製流程需要更多努力。您應考慮並評估未來變更如何防止自訂無法運作的風險。

調整潛力

由於諸如工作日的常見趨勢等因素，開發工作負載可能波動。例如，確認總結觸發 CI/CD 處理作業的當日結束活動，會造成工作天結束時的工作負載增加。隨著專案在建置、發行及部署生命週期的進展，建置基礎架構視需要增加。在版本 / 衝刺週期結束時，會處理少量問題，因此小型變更要求會增加。

複查決策矩陣

架構和解決方案以常見的數字組成群組，例如 1a、1b 和 1c，視它們有細微變化的位置而定。 例如，CI/CD 解決方案的單一節點或具有不同工具組態的相同解決方案，代表該解決方案可以大規模運作。每個分組都是決策矩陣中的資料欄標頭，每個因子都是一個資料列標頭。表格中的註標 (例如 1) 提供其他資訊。

架構與解決方案群組

  1. Jenkins 協調流程 (有兩個變化)
    1. 使用 Jenkins 設定雲端部署的 CI/CD 管線 ：最小的部署方法，無須擴展或彈性
    2. 以主要 / 代理程式模式部署 Jenkins ：可擴展且具有復原能力的部署
    3. 使用 Oracle DevOps 服務建置持續整合和部署管道
  2. GitLab
    1. 部署 GitLab 以在 OCI 上啟用 CI/CD 管線
    2. 使用叢集自動調整功能在 Oracle Container Engine for Kubernetes 上部署 GitLab 執行器
  3. OCI DevOps：無伺服器與容器的變體
    1. 使用 Oracle Cloud Infrastructure DevOps 服務和 OCI Functions 建置 CICD 管線
    2. 使用 Oracle DevOps 服務建置持續整合和部署管道
  4. GitHub 動作： 使用 GitHub 動作和 Oracle Cloud Infrastructure DevOps 服務為雲端部署建立 CI/CD 管道
  5. 現代化 App 策略： 使用 Oracle Cloud Infrastructure Devops 規劃現代 App 部署策略
  6. 行動中心： 建立行動應用程式的 CI/CD 管道
  7. 機器人： 為機器人自訂元件建立 CI/CD 管道

下列決策矩陣代表架構與解決方案之間的變化，可讓您根據業務需求識別適當的項目。

係數 1.Jenkins 協調 2.GitLab 3.OCI DevOps 4.GitHub 動作 5. 現代化 App 策略 6. 行動中心 7. 機器人程式
容器、虛擬機器 (VM) 或專家

VM 和容器

(雖然提供的解決方案目標 VM)

 VM 或容器 VM 與容器 VM 和容器 VM 和容器 專員 專員
透過開放原始碼 / 第三方產品進行 OCI 原生或未受管理的管線協調 是 是 不是 是 不是 否 (Oracle 開發雲) 不是
標準化部署儲存區域 是 1、3 是1 不是 沒有 (在 RA 實作中 - 但可能) 是1 不是 不是
支援的組態管理儲存區域 GIT、SVN 和其他 GIT GIT GIT GIT GIT GIT
多雲端或單一雲端部署 單一 2、3 單一或多重雲端 單一 2 單一或多重雲端 單一 2 單次 不是
處理自訂或訂製流程 是 是 是 是 是 不是 限制
調整潛力

1a - 否

1b - 是

 是 是 是 是 不是 不是

表格註腳

備註：

  • 1 OCIR 符合標準。
  • 2 使用 OCI 來驅動其他環境中的程序。但也引發了對其他環境服務暴露的挑戰。
  • 3 在部署階段中使用 OCI DevOps 選項 1a，因此將階段限制為單一雲端。