Recently I had multiple discussions on deployment topics regarding SAP components such as ABAP programs, SAP UI5 apps and respective challenges to adopt modern continuous integration/deployment processes provided by tools like Jenkins or Azure DevOps.
There are a couple of blog entries on how to integrate ABAP Unit, SAP Code Inspector etc with Azure DevOps already, so I would like to take the opportunity to showcase flexible deployments for UI5 apps using Azure DevOps. We are going to look particularly at canary releases, but the approach can be easily extended to support A/B Testing for example.
Nowadays zero-downtime deployment (including safe rollback) is not enough. Playing with new features and even variations of it comparing user adoption as well as testing releases with a small portion of the end-user base is crucial. So, we are looking beyond simple deployment slot swapping (commonly referred to as blue/green deployment). That is where canary releases and A/B Testing come into play.
Fig 1. popular deployment styles
Canary releases describe deployments where the new feature is exposed only to a small set of the user base currently using your app. That way you can reduce the risk of testing in production and get immediate feedback. A/B Testing uses similar routing mechanisms but focuses on deploying variations of features to be able to compare user reactions/adoption to it.
Wouldn’t it be great to be able to do that with your SAP UI5 apps? Today is your lucky day!
Closer Look at the implementation details
Imagine you want to be able to develop in SAP WebIDE and still profit from the app hosting capabilities of a cloud hyperscaler like Azure. I put together a fully working example for canary releases. You can find the sources on GitHub and the public DevOps project here. The concepts utilized can be applied to alternative software stacks and are not limited to Azure Cloud.
I chose this setup because it is quite easy to deploy but still rich in functionality. Azure App Service for Containers for instance covers deployment slots and traffic routing under the hood for you out of the box. Now, let’s have a look at the architecture:
Fig. 2 UI5 canary release on Azure with DevOps
- Every Git push to GitHub triggers the build process in Azure DevOps. This is initiated by the Developer from SAP WebIDE. (1)
- The build process runs a Dockerfile to create an image containing the updated SAPUI5 code from GitHub, a NGINX web server instance and pushes the result to a Container Registry – in my case Azure Container Registry (ACR). (2-4)
- Once finished the release pipeline picks up the latest image on ACR and deploys it on Azure App Service for Containers to the “Dev” slot, while adjusting the routing for the app. Now 5% of the end-users are routed to the “Dev” slot running the adjusted app, while 95% still see the former productive app. Check the Azure documentation for the necessary CLI commands. (5-7)
- The complete swap to the new version of the app is paused until a developer in Azure DevOps approves the last stage in the process (see orange dot in the figure above). (8-9)
There are many ways to implement an approval process for such scenarios for example with quality gates to name just one other option. I was looking for a quick and easy approach for this example. Therefore, manual approval by me was enough.
Note on the side: Since the integration works through GIT this will work with SAP’s next generation IDE SAP Business Application Studio too. It was announced on TechEd this year. Though still in beta it might be worth a look although SAP says WebIDE Full stack will be the tool for productive scenarios for a while still.
My example is focused on the UI part of the application. For a fully productive scenario you will need to think about scalability and versioning of software components (OData services etc.) on your backend as well. One way to approach this is query parameters like you might have seen with API versioning. However, keep in mind that my write up suggests “testing” in production.
So, in terms of ABAP developments this might impact your SAP transport strategies. I’d like to mention one common solution to this: dark deployments. By that I mean parts of your ABAP code that runs only under certain circumstances. You can imagine configurations (flags or query parameters) in your UI5 app that activate additional or alternative code sections on the backend. This approach applies to canary releases and A/B Testing.
That’s it regarding matching features on the UI with your backend. But what about Scale? Scaling SAP backend systems in general is a typical use case for today’s Cloud providers. From my perspective there is no point in being able to scale your web app infinitely depending on demand but to keep your backend static as is. But that is a topic for another blog post.
I gave a short introduction on popular deployment styles and showed you how a modern “canary release” could be implemented for your UI5 app, while developing in SAP WebIDE and leveraging Azure Cloud components for app services and Azure DevOps for CI/CD.
Building on top of my CI/CD example you could get really “crazy” and start building automation solutions for the cloud app itself to scale up/down and in/out depending on demand based on metrics for example.
To get you started quickly I added a build pipe to my Azure DevOps project that executes Terrafrom scripts to spin up the necessary Azure components. You will need to finalize the configuration in Azure DevOps though.
In my next blog I will extend this example to work with Kubernetes too. It doesn’t get more flexible in terms of deployment capabilities than that.
Find my GitHub repository here: https://github.com/MartinPankraz/UI5OnAzure
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.