关于javascript:SAP-Commerce-Cloud-的构建过程学习笔记

SAP Commerce Cloud 中的构建过程，会依据客户的 Github 代码存储库中的信息，构建出最终运行的软件。

Github 仓库的一个例子如下：

Commerce Cloud 中的构建过程蕴含下列这些操作：

• 克隆蕴含了客户实现我的项目 Customization 的 Github 仓库
• 下载所需的 artifacts
• 构建最终软件
• 将软件打包到 Docker 镜像中
• 将镜像上传到 Docker 注册表
• 返回无关要在指标 Commerce Cloud 环境中启用的服务的信息

其中关于软件打包到 Docker 镜像以及上传到 Docker 注册表的细节，能够查看我之前的文章：

• Docker 实战教程之从入门到进步 (一)
• Docker 实战教程之从入门到进步 (二)
• Docker 实战教程之从入门到进步 (三)
• Docker 实战教程之从入门到进步 (四)
• Docker 实战教程之从入门到进步 (五)
• Docker 实战教程之从入门到进步 (六)
• Docker 实战教程之从入门到进步 (七)
• Docker 实战教程之从入门到进步 (八)

构建过程会思考 Core-customize 和 js-Storefront 这些 Customization.

在构建过程刚刚开始时，它就试图确定每个 Docker 镜像的预期内容的哈希码。

Hash code 的计算蕴含下列多种因素，例如：

• Artifacts 版本
• 根本镜像版本
• 我的项目代码存储库的内容

而后它查看标记有这种哈希的镜像是否在 Docker 注册表中可用：

• 如果可用，将跳过镜像构建，间接在部署中应用现有镜像。
• 如果它不可用，将执行残缺映像构建并在部署中应用新镜像。

对于 JavaScript Storefront 来说，生成的 Docker 镜像，蕴含下列内容：

• Javascript storefront (蕴含 static content)
• Javascript storefront (反对 服务器端渲染 server-side rendering)

构建过程会生成部署期间应用的服务和 Docker 映像的列表。某些服务是可选的，并且确定了无奈自定义的镜像版本。

服务及其镜像的最终列表如下所示：

• Accelerator 店面服务：定制化之后的平台镜像
• Backoffice 服务
• admin 服务
• API 服务
• Solr 服务
• Zookeeper 服务
• 图像处理服务
• Data Hub 服务
• Javascript 店面服务
• Javascript 店面 SSR 服务

构建过程将此列表传递给部署过程。