SAP Commerce Cloud 中的構建過程，會根據客戶的 Github 程式碼儲存庫中的資訊，構建出最終執行的軟體。

Github 倉庫的一個例子如下：

Commerce Cloud 中的構建過程包含下列這些操作：

• 克隆包含了客戶實現專案 Customization 的 Github 倉庫
• 下載所需的 artifacts
• 構建最終軟體
• 將軟體打包到 Docker 映象中
• 將映象上傳到 Docker 登錄檔
• 返回有關要在目標 Commerce Cloud 環境中啟用的服務的資訊

其中關於軟體打包到 Docker 映象以及上傳到 Docker 登錄檔的細節，可以檢視我之前的文章：

• Docker 實戰教程之從入門到提高 (一)
• Docker 實戰教程之從入門到提高 (二)
• Docker 實戰教程之從入門到提高 (三)
• Docker 實戰教程之從入門到提高 (四)
• Docker 實戰教程之從入門到提高 (五)
• Docker 實戰教程之從入門到提高 (六)
• Docker 實戰教程之從入門到提高 (七)
• Docker 實戰教程之從入門到提高 (八)

構建過程會考慮 Core-customize 和 js-Storefront 這些 Customization.

在構建過程剛剛開始時，它就試圖確定每個 Docker 映象的預期內容的雜湊碼。

Hash code 的計算包含下列多種因素，例如：

• Artifacts 版本
• 基本映象版本
• 專案程式碼儲存庫的內容

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

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

對於 JavaScript Storefront 來說，生成的 Docker 映象，包含下列內容：

• Javascript storefront ( 包含 static content )
• Javascript storefront ( 支援 伺服器端渲染 server-side rendering )

構建過程會生成部署期間使用的服務和 Docker 映像的列表。某些服務是可選的，並且確定了無法自定義的映象版本。

服務及其映象的最終列表如下所示：

• Accelerator 店面服務：定製化之後的平臺映象
• Backoffice 服務
• admin 服務
• API 服務
• Solr 服務
• Zookeeper 服務
• 影象處理服務
• Data Hub 服務
• Javascript 店面服務
• Javascript 店面 SSR 服務

構建過程將此列表傳遞給部署過程。