Managing Build and Deployment Processes

During the development phase:

1. Developers push custom extension code and configurations to the Git-based code repository.
2. Developers also implement the manifest.json file to reference:
   1. The custom extension code and configurations that contain the business-specific implementation
   2. Various SAP Commerce Cloud extensions, such as the cloud hot folder extension or media conversion extension

1. The System Administrator uses the Cloud Portal UI to initiate a build.

   A build refers to all artifacts produced by the Builder component according to the application definition found in the manifest.json file within the Git repository.

2. Based on the manifest.json, the Builder retrieves custom extension code and SAP Commerce Cloud extensions, compiles them, and generates security-hardened Docker images on top of a base image.
3. Following a successful build, the system registers the generated images in a container registry.

You can monitor the build progress and review the steps on the build details page of the Cloud Portal.

A build can exist in the following four stages:

• After a system administrator creates a new build, it assumes a Scheduled state, meaning the Cloud Automation Engine has queued it for scheduling. Depending on the existing workload and capacity of the Cloud Automation Engine, the build may take a few seconds or minutes to start.
• When in the Building state, the Builder Component retrieves the project code from the Git repository and compiles it.
• If the build concludes successfully, it transitions to the Success state, indicating readiness for deployment to a cloud environment.
• However, if any part of the build process goes wrong, the build assumes a Failed state.

For failed builds, review the log file. There are numerous reasons a build might fail, such as:

• Outdated Commerce Cloud versions that are no longer supported.
• The Cloud Automation Engine cannot access customer Git repositories.
• Code-level issues like syntax errors or missing dependencies.

A successful build can then be deployed to a cloud environment. Next, let's examine the deployment phase.

As depicted in the diagram:

1. Through the Cloud Portal UI, a system administrator deploys a successful build to a cloud environment.
2. The deployment request activates the Deployer component, which retrieves the Docker images from the container registry and places them onto the Kubernetes cluster nodes.
3. Docker containers are produced from these images, which are then run on the cluster nodes (e.g., the customized SAP Commerce Cloud Application in the S1 environment).

To initiate a deployment, select a successful build, go to the build details page, and select the Deploy to Environment button at the top right.

On the deployment configuration page, you can deploy the selected build. Ensure you set the values for the following three elements:

1. Target Environment

   Select the target environment where you want to deploy the selected build. This could be the Development, Staging, or Production environment.

2. Platform Update Mode

   Platform Update Mode indicates which item types or data changes the current build includes. Its possible values are:

   • No migration required implies the build includes no modifications to the type system (items.xml) or data (impex). It only incorporates changes to the code and configuration files.
   • Migrate data suggests the build includes changes to the type system or item data, requiring updates to the type system or existing item data in the database.
   • Initialize database is typically used for initial deployments and requires a complete rebuild of the database schema.
3. Deployment Mode

   Deployment Mode outlines how to apply the current build to the Kubernetes cluster:

   • Rolling Update: Is typically used for Production environments and involves deploying the build to the cluster one server at a time. The entire cluster remains operational, with at least one server available to handle live traffic.
   • Recreate: Is commonly used for initial deployments to Production environments or regular deployments to Development or Staging environments. It deploys the build to all the servers in the cluster simultaneously, destroying and recreating all existing servers in the cluster from the build. This means the cluster is entirely non-operational and cannot service traffic during deployment.
   • Blue/Green: The blue/green deployment function adds a layer of protection to future deployments (green) by offering a preview in production prior to its official launch to customers. For more details, please refer to: Blue Green Deployments | Help Portal.

• Build process: A system administrator initiates a build via the Cloud Portal, triggering the Builder to compile custom and SAP Commerce Cloud extensions into security-hardened Docker images. Builds move through three states - Scheduled, Building, and finally either Success or Failed - with the log file as the key resource for diagnosing failures.
• Deployment configuration: Deploying a successful build requires setting three parameters in the Cloud Portal: Target Environment (Development, Staging, or Production), Platform Update Mode (No migration required, Migrate data, or Initialize database), and Deployment Mode (Rolling Update, Recreate, or Blue/Green), each suited to specific deployment scenarios.
• Additional access methods: Beyond the Cloud Portal UI, administrators can also manage builds and deployments programmatically using the SAP Commerce Cloud REST APIs or the downloadable Command Line Interface (CLI) tool.