SAP 电商云构建过程的次要步骤，能够通过上面这张图形容：
- 将蕴含了客户 project customizations 的 Github repository 进行克隆。
- 下载必须的 package.
- 执行 customizations 过程。
- 进行构建，将后果打包成 docker 镜像。
- 将 docker 镜像上传到 Docker registry.
在构建过程中，以下几个步骤能够定制化：
- core commerce
- Data Hub
- Javascript storefront
每个步骤进行定制化，存储的文件夹都不雷同：
每次构建之后，Commerce Cloud 打包过程，会依据下列因素，计算一个 Docker image 的 hash 进去：
- The artifact versions.
- Base image versions.
- 我的项目代码仓库的内容
而后查看标记有这种 hash 的镜像是否在 Docker 注册表中可用：
- 如果可用 – 将跳过映像构建并在部署中应用现有映像。
- 如果它不可用 – 将执行残缺映像构建并在部署中应用新映像。
针对 Spartacus Storefront，构建之后会生成独自的 docker 镜像：
一个准则是同一个构建能够与多个 Commerce Cloud 环境一起应用。这种办法的长处是在开发或登台环境中测试的雷同代码被部署到生产环境中。因而，构建配置里不能蕴含和具体环境相干的条目，上面是一些例子：
- Domain names.
- IP address.
- SSL certificates.
- URLs or credentials to any external systems.
- Credentials for technical users.
这些 environment specific 的配置不能呈现在构建配置里，否则就和具体的 environment 产生了强耦合。
SAP Commerce Cloud 环境的类型有开发、staging 和生产三种。这些类型也称为 persona。
环境角色影响环境的性能和环境应用目标。个别规定是生产环境比 staging 环境的访问速度快，而 staging 比开发访问速度快。环境能够具备不同的配置，例如不同的 service properties.
如果的确要进行环境相干的配置，能够保护在 Cloud Portal 里。