SAP Commerce Cloud Github 仓库管理规范

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

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

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

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

看个具体的例子。

有一个项目存储库，它包括下列资源：

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 店面服务未重新启动。因为对应的镜像或配置没有变化。