SAP 電商雲構建過程的主要步驟，可以透過下面這張圖描述：

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

1. 將包含了客戶 project customizations 的 Github repository 進行克隆。

2. 下載必須的 package.

3. 執行 customizations 過程。

4. 進行構建，將結果打包成 docker 映象。

5. 將 docker 映象上傳到 Docker registry.

在構建過程中，以下幾個步驟可以定製化：

- core commerce
- Data Hub
- Javascript storefront

每個步驟進行定製化，儲存的資料夾都不相同：

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

每次構建之後，Commerce Cloud 打包過程，會根據下列因素，計算一個 Docker image 的 hash 出來：

1. The artifact versions.
2. Base image versions.
3. 專案程式碼倉庫的內容

然後檢查標記有這種 hash 的映象是否在 Docker 登錄檔中可用：

- 如果可用 - 將跳過映像構建並在部署中使用現有映像。
- 如果它不可用 - 將執行完整映像構建並在部署中使用新映像。

針對 Spartacus Storefront，構建之後會生成單獨的 docker 映象：
![](https://img-blog.csdnimg.cn/img_convert/92ffcad265abe6777be37d9f189f0c46.png)

一個準則是同一個構建可以與多個 Commerce Cloud 環境一起使用。 這種方法的優點是在開發或登臺環境中測試的相同程式碼被部署到生產環境中。因此，構建配置裡不能包含和具體環境相關的條目，下面是一些例子：

- Domain names.
- IP address.
- SSL certificates.
- URLs or credentials to any external systems.
- Credentials for technical users.

這些 `environment specific` 的配置不能出現在構建配置裡，否則就和具體的 environment 產生了強耦合。

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

SAP Commerce Cloud 環境的型別有開發、staging 和生產三種。 這些型別也稱為 `persona`。

環境角色影響環境的效能和環境使用目的。 一般規則是生產環境比 staging 環境的訪問速度快，而 staging 比開發訪問速度快。 環境可以具有不同的配置，例如不同的 `service properties`.

如果確實要進行環境相關的配置，可以維護在 Cloud Portal 裡。

SAP 電商雲的構建過程中涉及到的三種不同環境型別

相關文章