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 服務
構建過程將此列表傳遞給部署過程。