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 里。
