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 服务
构建过程将此列表传递给部署过程。
