SAP Commerce Cloud 使用单个 Git 存储库作为项目 Customization 的来源,采用单一构建过程来构建整个应用,并且将整个应用程序的构建结果,采用单一部署过程部署到目标环境。

Commerce Cloud 构建过程使用递归选项克隆项目存储库。它允许您将其他存储库(称为Sub modules)插入主存储库。 当多个团队为同一个项目存储库做出贡献时,这种方法很有用。 每个存储库可以使用不同的分支策略或具有不同的权限规则。

从 Commerce Cloud 的角度来看,这种方式仍然像单个存储库一样工作:

  • Commerce Cloud 构建过程会克隆主存储库的给定分支的最近提交。
  • 主存储库的某一个路径,可以指向特定路径和单独存储库(git 子模块)的特定提交。
    所有单独的存储库都使用相同的凭据进行访问,这些凭据在 Cloud Portal 中为主存储库配置。

SAP Commerce Cloud Github 仓库管理规范

看个具体的例子。

有一个项目存储库,它包括下列资源:

  1. core Customization 核心定制,其中存储在子模块 1 中的扩展 1 和 2,扩展 3 和 4 存储在子模块 2 中。

  2. JavaScript 店面存储在子模块 3 中。

在某个时间点,开发人员更改了子模块 1 中的扩展 1。

  • 为了反映主存储库中的更改,还必须对主存储库进行提交,更改对子模块 1 的引用,以指向其最近的更改。

  • 最终用户触发 Commerce Cloud 中的新构建。

构建过程进行的变更分析和检测:

  • 必须构建新的平台镜像,因为扩展 1 发生了变化。

  • 可以重复使用现有的 Solr 镜像,因为操作系统、Solr 或 Commerce Cloud 版本没有变化,Solr 定制没有变化。

  • 可以重复使用现有的 Zookeeper 镜像。因为操作系统或 Zookeeper 版本没有变化。

  • 可以重复使用现有的 JavaScript 店面镜像。 JavaScript 店面自定义没有变化。

最终用户触发新构建的部署:

  • 有一个新的平台镜像,因此所有基于平台的服务都将重新启动。
  • Solr 和 Zookeeper 服务不会重新启动。因为对应的镜像或配置没有变化。
  • JavaScript 店面服务未重新启动。因为对应的镜像或配置没有变化。