1. 了解如何选择合适的 CI/CD 体系结构
  2. 确定最适合的体系结构或解决方案

确定最适合的体系结构或解决方案

考虑一系列评估因素（或压力因素），以确定最符合您需求的参考架构 (RA) 或解决方案。以下各节提供了有关应考虑的因素的信息。

对于每个因素，我们向您指示体系结构或解决方案是否支持该因素。如有必要，可以通过为每个因素指定数字分数使其更加细化。使用这些建议的信息和决策矩阵。

  • 跟踪哪些列符合您的首选答案。
  • 使用决策矩阵将最符合您的需求的 RA 或解决方案与每个评估因素进行比较。
  • 添加比其他因素更重要的因素的权重。

考虑各种评估因素

考虑每个评估因素，然后将它们与每个体系结构和解决方案进行比较，以确定最适合您需求的因素。

容器、虚拟机 (VM) 或专家

您可以将流程部署到容器编排环境（例如 Kubernetes）中的容器，从而高效扩展对计算能力要求更高的流程的资源。单元测试和静态代码分析等任务可能会从中受益。使用容器的缺点是端到端配置的复杂性增加。您的团队需要了解如何使用容器编排工具，例如 Kubernetes。使用容器还可以确保在销毁容器时，防止意外获取瞬态依赖关系或以前的状态数据。

使用 VM 更简单，因为您可以构建单个 VM 来处理管道的所有步骤。容器本质上是单体式的。VM 方法还缓解了允许开发人员托管等问题，并避免了使用 Windows 与 Linux 主机的问题。

某些专家方案仅支持 PaaS 或 SaaS 产品，其中构建过程准备并部署服务的对象。您可以使用通用工具编排此流程。在某些情况下，使用特定于需求的工具会更有益。例如，Oracle Visual Builder Studio 专为涉及 Visual Builder 的解决方案而设计。

使用 OCI 原生技术与开源/第三方产品的管道编排

与使用 OCI 本机解决方案相比，使用特定于域或可定制的工具（包括 Jenkins 等开源工具）可以在执行期间在构建过程中提供更大的自由。尽管 OCI DevOps 等工具定期发布新功能。但是，即使在执行典型的管道时，这种灵活性也是管理更多流程阶段（例如部署、打补丁和监视）的成本所在。

标准化部署资料档案库或特殊产品资料档案库

使用 OCI Git、GitLab 或 GitHub 等行业标准服务以及类似工具管理配置时，原生服务将满足您的需求。CI/CD 进程可能会受到部分集成的旧系统信息库的限制。您可能需要对管道进行重大更改，才能将 CI/CD 流程与旧系统信息库结合使用。

行业标准配置管理或传统工具

使用云提供的服务时，典型的服务是仅支持使用配置管理 (Configuration Management，CM) 系统（例如 Git 和 SVN）的行业标准解决方案。这些服务提供商还可以支持供应商自己的产品所需的任何专家配置管理机制。如果您必须使用传统或独特 CM 系统，则可能需要考虑 CM 系统提供商支持的第三方解决方案。例如，对 CVS 作为传统解决方案的支持可能需要用户使用第三方工具来管理配置。

多云部署或单一云部署

将同一核心解决方案部署到多个云可能会增加您应该考虑的复杂性。例如，如果部署流程已整合到 Terraform 服务中，则每个云提供商都将需要部署流程来考虑不同 Terraform 提供商的差异。由于需要创建不同的映像，因此可能需要考虑更多细微的注意事项，例如 Docker 映像的目标芯片集。

为了确保更好的安全性，您可以选择不公开外部部署解决方案的部署目标。例如，如果要部署到 Oracle Container Engine for Kubernetes (OKE) 和 Azure Kubernetes (AKE)，则可以使用 GitHub 保存公用代码和 GitHub Actions 来编排容器构建。但是，您可以选择不直接向 GitHub Actions 公开 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 功能构建 CICD 管道
    2. 使用 Oracle DevOps 服务构建连续集成和部署管道
  4. GitHub 操作： 使用 GitHub Actions 和 Oracle Cloud Infrastructure DevOps 服务为云部署构建 CI/CD 管道
  5. 现代应用战略： 使用 Oracle Cloud Infrastructure Devops 规划现代应用部署战略
  6. 移动中心： 为移动应用创建 CI/CD 管道
  7. 机器人： 为机器人定制组件创建 CI/CD 管道

以下决策矩阵表示架构和解决方案之间的差异，以便您根据业务需求确定合适的架构。

因子 1.Jenkins 业务流程 2.GitLab 3.OCI DevOps 4.GitHub 操作 5. 现代应用策略 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 在选项 1a 的部署阶段使用 OCI DevOps，因此将该阶段限制为单个云。