Managing Build and Deployment Processes

During the development phase:

1. Developers push custom extension code and configurations to the Git based code repository.
2. Meanwhile, implementation is carried out on the manifest.json file to make references to:
   • 2a: The custom extension code and configurations which contain the business-specific implementation
   • 2b: Various SAP Commerce Cloud extensions, such as the cloud hot folder extension or media conversion extension, among others.

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. The build retrieves custom extension code and SAP Commerce Cloud extensions based on the manifest.json, compiles them to generate 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. This implies that it is queued for scheduling by the Cloud Automation Engine and accessed by multiple SAP customers within the same data center. Depending on the existing workload and the capacity of this 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.

Note: Upon completion of a build (irrespective of whether it is successful or not), you may download the build log file (see the previous image) from the build page:

• For successful builds, there's no need to read the log file, which could contain thousands of lines of detailed information, unless you wish to thoroughly analyze the build process.
• For builds that have failed, it's necessary to study the log file using a text editor and navigate to the bottom to uncover any error or exception information. This should provide a general understanding of what occurred during the build and why it failed. There are numerous reasons a build might fail, such as:
  • Outdated Commerce Cloud versions that are no longer supported.
  • Inaccessibility of customer Git repositories by the Cloud Automation Engine.
  • Code-level issues like syntax errors or missing dependencies.

Finally, a successful build can 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 can deploy a successful build to a cloud environment.
2. Subsequently, the Deployer component is activated by the deployment request. It retrieves the Docker images from the container registry and places them onto the Kubernetes cluster nodes.
3. Ultimately, Docker containers are produced from these images, which are then operated on the cluster nodes (for example, the customized SAP Commerce Cloud Application in the S1 environment).

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

On the deployment configuration page, you're ready to deploy the selected build. Ensure you set the values for the following three elements:

1. Target Environment

   The selected build is intended for deployment in the target environment. This could be the Development, Staging, or Production environment.

2. Platform Update Mode

   The Platform Update Mode indicates which item types or data changes are incorporated in the current build. Its possible values include:

   • No migration required: Implies no modifications to the type system (items.xml) or data (impex) are included. Therefore, the build only incorporates changes to the code and configuration files.
   • Migrate data: Suggests that changes to the type system or item data are included. Therefore, deployment requires updates to the type system or existing item data in the database.
   • Initialize database: Is typically used for the initial deployment and indicates that the database schema must be completely rebuilt from the ground up.
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. Therefore, 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 involves deploying the build to all the servers in the cluster simultaneously. Consequently, all existing servers in the cluster are destroyed and recreated 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. More details can be found in the Blue Green Deployments | Help Portal.