What is Blue-Green Deployment?

Blue-Green Deployment in SAP BTP Cloud Foundry is a reliable strategy for updating applications with zero downtime and minimal risk. The concept revolves around maintaining two identical environments:

Blue – the current live environment actively serving users.
Green – the new version of the application, deployed in parallel for testing and validation.

While end-users continue working in the Blue environment, developers can safely deploy and verify the updated application in Green. This allows for functional testing, performance checks, and integration validation without affecting live operations.

Once the Green environment is confirmed to be stable and fully functional, traffic is seamlessly redirected from Blue to Green, making it the new production environment. If any issues arise after the switch, rollback is straightforward—traffic can quickly be pointed back to Blue, ensuring business continuity.

SAP BTP supports this deployment approach through the Cloud Foundry CLI and Multi-Target Application (MTA) deployment tools, making it particularly well-suited for rolling out updates to mission-critical business applications where even a few minutes of downtime is unacceptable. This method not only improves release reliability but also enhances user confidence in the stability of new updates.

Key Advantages:

Zero Downtime Deployments
Quick Rollback
Improved Business Continuity

Restriction:

Blue Green deployment is supported only for cloud foundry application. It is not supported for there bounded services, such as workflow content and HTM5 repository content and others.

I assume that you have knowledge of:

Knowledge of SAP BTP CAPM development.
SAP BTP Cloud Foundry
Basic Postman
OData API understanding.

Demonstration:

Step 1:

Assume you’re working on a BTP CAPM project that has already been deployed in the Cloud Foundry environment. Below is a screenshot of a basic CAPM project containing two entities:
Books and Authors

Step 2:

Below is a screenshot of Cloud Foundry Space, showing the live services

Step 3:

Below is a screenshot of calling the service using Postman:

Step 4:

The above CAP project has been built and deployed in the Cloud Foundry environment. A new requirement has now been introduced to create an additional entity named ‘E-Books’

Modify the entity and service .cds file as below:

You can test the services locally by executing Command: “cds watch”

Step 5:

Now, we build the project using

1. CLI: cds build –production. OR
2. Right Click MTA file and build.

The Build will start:

Step 6:

After the build is finished, change the directory to “mta_archives”, using command:

>>> cd mta_archives

Step 7:

We will now use the Blue-Green deployment strategy to carry out testing before promoting the changes to the live environment.

Please note we need to make use of CLI to use the strategy.

Command format:
>>>>> cf deploy <your-mta-archive-v2> --strategy blue-green

Actual Command (for the project):
>>>>  cf deploy BlueGreenDemo_v1_1.0.0.mtar --strategy blue-green

Step 8:

The deployment process will begin shortly. You can monitor its progress—a new service instance with the suffix -idle will be created as part of the Blue-Green deployment strategy

Finally, the service are now deployed.

Save the following commands, as this specifies the process ID’s of blue green deployment.
Use “cf deploy -i 2355087a-572f-11f0-aeea-eeee0a8c175e -a abort” to abort the process.
Use “cf deploy -i 2355087a-572f-11f0-aeea-eeee0a8c175e -a resume” to resume the process.process.
Hint: Use the “–skip-testing-phase” option of the deploy command to skip this phase.

Hint: Incase the above process id is lost because of terminal closed. You can get the process id using command

>>>>> cf mta-ops

Also, the above shows the status that action is required for MTA to either be aborted or resumed.

Step 9:

Check under the cloud foundry dev space in SAP BTP:
As seen in the screenshot below:
We have and Idle and live services running.

Step 10:

Check the service status using CLI :
Command: cf apps

Let’s test the idle service using postman:

The Idle service has 3 entities defined in it:

1. Books
2. Authors
3. Ebooks

Let’s check the live services as of now:
The live services are still showing 2 entities:

1. Authors
2. Books

Step 11:

Let check the commands that were saved during the deployment:
Use “cf deploy -i 2355087a-572f-11f0-aeea-eeee0a8c175e -a abort” to abort the process.

The above command is used to abort the deployment process. This is typically done when the changes deployed to the idle service do not meet the requirements. In such cases, the deployment process can be safely aborted without affecting the live environment, thereby preventing unintended changes from being promoted to production and preventing the effort of reverting the changes.

However please note:

This action does not perform a rollback, and the state of apps, routes and services remains unchanged. Depending on your needs, you might want to remove the new app versions and the temporary routes.
Let’s use the command to see the effects of:
As soon as you use the command, the process is aborted: