在构建时，SAP Commerce Cloud 规范的文件目录是可写的，因为构建过程自身须要批改这些文件目录。然而不举荐客户的 Customization 里也对这些 SAP Artifacts 做批改，因为这违反了开闭准则，可能会引起潜在的问题。SAP 举荐客户应用 Commerce Cloud 自带的 Extension 机制来进行定制化。
不要在不受构建过程治理的任意目录中写入任何内容，即便这些目录从技术上来说是处于可写状态的，也不要这样做。这是因为因为优化或平安改良，这些不受构建过程治理的目录，未来可能会从新变成不可写入状态，从而导致构建过程失败。
在构建过程中，默认认为 Github 仓库和 Docker Registry 都是处于可拜访状态。然而无奈保障构建过程具备不受限制的互联网拜访权限。在构建过程中不要应用任何内部服务，因为出于优化或平安改良的目标，网络策略可能随时更改。构建过程可能管制的惟一资源就是我的项目 Git 存储库。
Commerce Cloud 构建过程不为第三方 Artifacts 提供任何受信赖的存储库。默认状况下，它应用公开可用的存储库。
以下是存储库应用状况的细分：
- 如果在 extensioninfo.xml 中启用，外围定制应用 Maven Central 进行散发
- JavaScript Storefront 应用 yarn 工具配置的默认注册表
[图片]
对于 yarn 和 npm – 在开发过程中解决依赖关系并将 yarn.lock.json 或 package-lock.json 文件提交到代码存储库中。这样做的目标是，对于雷同的输出，即便反复构建，也能失去雷同的输入。
属性文件是蕴含用于配置管理的键值对的规范 Java 文件。上面是一个例子：
能够应用三种不同的形式为 SAP Commerce Cloud 和 Data Hub 设置属性：
- 在 Cloud Portal 中将它们设置为 Service Properties
- 应用服务特定清单即 Service specific Properties
- 筹备属性文件，将它们放在存储库中，并应用 useConfig 清单组件来援用它们。