一卷旌收千骑虏,万全身出百重围。这篇文章主要讲述SAP Commerce Cloud Github 仓库管理规范相关的知识,希望能为你提供帮助。
SAP Commerce Cloud 使用单个 Git 存储库作为项目 Customization 的来源,采用单一构建过程来构建整个应用,并且将整个应用程序的构建结果,采用单一部署过程部署到目标环境。
Commerce Cloud 构建过程使用递归选项克隆项目存储库。它允许您将其他存储库(称为Sub modules)插入主存储库。 当多个团队为同一个项目存储库做出贡献时,这种方法很有用。 每个存储库可以使用不同的分支策略或具有不同的权限规则。
从 Commerce Cloud 的角度来看,这种方式仍然像单个存储库一样工作:
- Commerce Cloud 构建过程会克隆主存储库的给定分支的最近提交。
- 主存储库的某一个路径,可以指向特定路径和单独存储库(git 子模块)的特定提交。
所有单独的存储库都使用相同的凭据进行访问,这些凭据在 Cloud Portal 中为主存储库配置。
看个具体的例子。
有一个项目存储库,它包括下列资源:
- core Customization 核心定制,其中存储在子模块 1 中的扩展 1 和 2,扩展 3 和 4 存储在子模块 2 中。
- javascript 店面存储在子模块 3 中。
- 为了反映主存储库中的更改,还必须对主存储库进行提交,更改对子模块 1 的引用,以指向其最近的更改。
- 最终用户触发 Commerce Cloud 中的新构建。
- 必须构建新的平台镜像,因为扩展 1 发生了变化。
- 可以重复使用现有的 Solr 镜像,因为操作系统、Solr 或 Commerce Cloud 版本没有变化,Solr 定制没有变化。
- 可以重复使用现有的 Zookeeper 镜像。因为操作系统或 Zookeeper 版本没有变化。
- 可以重复使用现有的 javaScript 店面镜像。 JavaScript 店面自定义没有变化。
- 有一个新的平台镜像,因此所有基于平台的服务都将重新启动。
- Solr 和 Zookeeper 服务不会重新启动。因为对应的镜像或配置没有变化。
- JavaScript 店面服务未重新启动。因为对应的镜像或配置没有变化。
推荐阅读
- ntpdate[2733]: no server suitable for synchronization found
- SAP 订单模型的编排方式概述
- SAP Commerce Cloud 构建环境和最终运行环境的区别
- 一种基于事件驱动思想的 SAP 系统集成二次开发方法介绍
- SAP Commerce Cloud 构建过程中的文件夹可写入性问题分析
- SAP GUI 一些实用技巧分享
- SAP Commerce Cloud 构建环境类型介绍
- 1.03 VMware安装
- 技术分享 | Selenium多浏览器处理