在构建时，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 文件。下面是一个例子：

![](https://img-blog.csdnimg.cn/img_convert/6f5ee0987ca3a2ba7e86a96ab6c9327b.png)

可以使用三种不同的方式为 SAP Commerce Cloud 和 Data Hub 设置属性：

- 在 Cloud Portal 中将它们设置为 Service Properties

-  使用服务特定清单即 Service specific Properties

- 准备属性文件，将它们放在存储库中，并使用 useConfig 清单组件来引用它们。

ITPub博客

SAP Commerce Cloud 构建过程中的文件夹可写入性问题分析

最新文章