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

【SAP Commerce Cloud 构建过程中的文件夹可写入性问题分析】一身转战三千里，一剑曾当百万师。这篇文章主要讲述SAP Commerce Cloud 构建过程中的文件夹可写入性问题分析相关的知识，希望能为你提供帮助。
在构建时，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 设置属性：