My last post on release strategies (e.g. canary) covered a nice example on how to implement an integrated CI/CD pipeline with SAP WebIDE, Azure DevOps and Azure App Service for Containers. Today I’d like to focus on a CI/CD integration scenario for Cloud Foundry.
SAP offers a nice one-click build and deploy integration feature for SAP WebIDE. Unfortunately, this is falling short of many requirements developers and customers have regarding flexible deployments like blue/green and instant rollback mechanisms in production. A common scenario nowadays is also to be able to release to multiple cloud platforms (Azure, AWS, GCP) from one code base.
There are multiple tools out there, that get the job done. Popular choices are Jenkins, Project Piper, GitHub Actions and Azure DevOps to name a few. I am going to focus on the latter today.
So, imagine you have an SAP Multi-Target Application (MTA) developed in SAP WebIDE, that you want to release to Cloud Foundry using blue/green deployment. I developed a fully working and publicly available example for the release process. Check the image below to get a feeling for the moving parts of the project that I am describing.
fig.1: Overview of all moving parts of today’s CI/CD undertaking
Short recap on Multi Target Applications: MTA is SAP’s answer to the challenge of moving multiple interconnected software components from one environment to another. SAP Cloud Platform (in our case using the Cloud Foundry environment) is smart enough to solve this software-component puzzle and automatically deploys every piece depending on the technology used, where it needs to be. Cloud Foundry expects the “puzzle” to be bundled in an MTA archive.
Let’s have a look how we can make Azure DevOps understand MTA projects and release to Cloud Foundry. But first things first. Here is how I setup my example project:
- Create a Multi Target Application from template in SAP WebIDE and add an HTML5 module
- Try to build it in WebIDE wit Cloud MTA Build to make sure everything is working fine
- Upload your sample project to GitHub for version control and accessibility in Azure DevOps as well as continuous integration on every Git pull request or push. Azure DevOps will run the MTA build once you are all set.
- Create a Cloud Foundry environment on your SAP Cloud Platform account. You can choose between the three hyper scalers (AWS, Azure, GCP). I picked AWS for a multi-cloud scenario because I am releasing from Azure DevOps
- Have a space on your subaccount available and be aware about the available quotas, your CF API endpoint and respective org name because you will need them to login from Azure DevOps.
- (Optional) Install CF CLI locally for troubleshooting purposes. That way you can check if you have your login details right for example: cf login -a https://api.cf.eu10.hana.ondemand.com/ -u <S-User> -p <your password> -o <org name> -s <space name>
- Create a project in DevOps
Get right into it
Now it is time to configure our build pipeline in Azure DevOps so we can build our MTA project, which we develop in SAP WebIDE or any other IDE, that understands the languages used in your MTA (e.g. Visual Studio Code, Eclipse etc.).
fig. 2: Screenshot of build pipe on Az DevOps
My build pipe runs on an ubuntu agent, which downloads SAP’s Cloud MTA build tool and executes the build immediately. After that I copy the resulting MTAR-file from the build directory to the staging directory, so that my release pipe can pick it up next.
Using the Cloud MTA build tool documentation and local testing with Powershell I was able to determine the right path for Azure DevOps: $(agent.builddirectory)/s/mta_archives.
Note on the side: I configured continuous integration from GitHub through the Triggers tab of the build pipe shown above.
wget https://github.com/SAP/cloud-mta-build-tool/releases/download/v1.0.5/cloud-mta-build-tool_1.0.5_Linux_amd64.tar.gz tar xvzf cloud-mta-build-tool_1.0.5_Linux_amd64.tar.gz sudo cp mbt /usr/local/bin/ npm config set @sap:registry https://npm.sap.com mbt build
fig. 3: Cloud MTA Build setup on Az DevOps
So far so good. We have a MTAR file, which Cloud Foundry can understand. What’s next? Remember, we wanted to do blue/green deployments.
Closer look at the release pipe
In general, this means you have two instances of your app running in parallel – typically, different versions of it. One of them is live (v1) and the other is idle (v2). Once you are happy with the new version you can swap the routes, so that v2 becomes live, without any disruption to the end users.
fig. 4: Blue green deployment
However, the implementation of the Cloud Foundry CLI plugin “bg-deploy” deletes the v1 deployment slot and idle routes once the swap finishes. You can find further info on the matter on the SAP docs here.
I configured a 2-stage deployment with CF CLI and modelled my release pipe in Azure DevOps accordingly. That way you can test the new version before performing the swap. Azure DevOps takes care of the approval process. Meaning, I get an approval request before the swap is initiated.
fig. 5: Az DevOps release pipe with approval setup
Both release tasks in dev and prod stages are similar and differ only in configuration parameter for the bg-deploy command.
fig. 6: Az DevOps release pipe dev stage setup
First, I install a recent version of the CF CLI on my agent to be and secondly execute the following set of commands:
cf install-plugin multiapps -f $mtar = Get-ChildItem -recurse *.mtar | Select FullName $target = $mtar.FullName echo "$target" cf login -a https://api.cf.eu10.hana.ondemand.com/ -u $ENV:MYSUSER -p $ENV:MYPASS -o $ENV:MYACCOUNT -s dev cf bg-deploy $target
fig. 7: Powershell script on dev stage in release pipe in Azure DevOps
Let’s walk through it.
- Install a plugin for the CF CLI, that allows MTA deployments
- Retrieve the file path to the MTAR-file, that I want to deploy. Note that I set the working directory for the Powershell task to the drop folder of the release pipe input.
- Login with the CF API using my S-User, password, org and space name to be able to work with my account. Note that I defined the parameters as secrets on the release pipeline and mapped them into the script using environment variables. You can learn more about that here.
- Do the actual deployment with the pre-bundled plugin for blue/green deployments.
After the dev stage of my release pipeline finishes you will see two instances on SAP Cloud Platform. That represents the intermediate state of the blue/green deployment as described in figure 4.
fig. 8: Release process intermediate state before approval
After all that, you are one approval away from releasing a new version of your app to production with state of the art CI/CD from SAP WebIDE to Cloud Foundry with zero-downtime (see upper part of figure 8).
Check out my last blog post on different release strategies with UI5 and Azure DevOps. You can get even more fancy than blue/green 😉
There are several ways to establish sophisticated and flexible release processes for your Multi Target Applications. I showed you one easy example with GitHub, Azure DevOps and the blue-green plugin of the CF API CLI that gets you a great deal of new possibilities.
Cloud Foundry’s serverless approach of: “Here is my source code. Run it on the cloud for me. I don’t care how.” really kicks off when you spice it up with some good CI/CD don’t you think?
By the way, my example application was running on SAP’s Cloud Foundry environment hosted on AWS. You can provision the same setup on GCP and Azure from the SAP Cloud Platform Cockpit too. So, you get to cherry pick your favourite environment.
Note on the side: All components used have a free trial.
Find my GitHub repository here: https://github.com/MartinPankraz/AzureWithUi5onCF
Public Azure DevOps project here: https://dev.azure.com/mapankra/SAPUI5onAzure
As always feel free to leave or ask lots of follow-up questions.
Opinions expressed are solely my own and do not express the views or opinions of my employer.