乐趣区

关于sap: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 设置属性:

  • 在 Cloud Portal 中将它们设置为 Service Properties
  • 应用服务特定清单即 Service specific Properties
  • 筹备属性文件,将它们放在存储库中,并应用 useConfig 清单组件来援用它们。
退出移动版