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

【腾讯云】轻量 2核2G4M,首年65元

阿里云限时活动-云数据库 RDS MySQL  1核2G配置 1.88/月 速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据