Application Lifecycle Management in Business Technology Platform

Let’s start with one of the most important topics: source code validation. Without a robust codebase, the resulting application(s) will never run in an optimal and performant way. To make the comparison between on-premise and cloud-based source code validation, we will use ABAP (which we all know, right?) and JavaScript, which is one of the most common scripting languages used in cloud development.

While ABAP development takes place in either Eclipse or SAP GUI, JavaScript development can happen in basically any plain text editor. Yes, even in Notepad! ABAP developments get checked automatically on the server before they get activated and can be executed.

This doesn’t mean the development will be without bugs, but at least we’re sure the right syntax was used. These standard syntax checks can optionally be extended by using ATC checks, which would check code for bad constructions and performance.

JavaScript, on the other hand, doesn’t automatically get validated when deployed to a server. This means that without proper testing, even the most basic syntax errors can make it to production. That would be regrettable.

Fortunately, tools like ESLint can help us out to validate and optimize our JavaScript code. Most popular development IDE’s even integrate ESLint by default or by installing a plugin. But then again, this code validation happens on the development machine and can be configured differently based on the developer’s preference.

Wouldn’t it be better if we could centralize this code validation like we’re used to in ABAP, for instance? This brings us to our next topic: source code management.

In ABAP-based systems, each change to a development object is tracked. A new version is automatically created. When something goes wrong, we can easily revert to a previous version. In other words, our ABAP-based system is our source code management system.

In cloud-based development, there is no such thing as automatic version management. We will need to introduce a separate source code management system like for example GIT. We will not go into details on what GIT offers, since we’re only looking into the solution from an application lifecycle management perspective. But basically, GIT allows us to track all our source code changes and revert to previous versions if needed.

Another great thing about GIT is that it can be integrated with a Continuous Integration (CI) server. Depending on the GIT provider, a Continuous Integration server can be built-in by default. With such a CI server it is possible to configure pipelines to perform automated source code validation (e.g. based on ESLint), automated integration and unit tests. With a CI server in place, we can easily centralize our code validation and ensure each developer uses the same standards and presets.

Also important to mention is that SAP provides a set of best practices and ready-to-use pipelines in the form of Project Piper. This can be used as-is or to set up your own custom pipelines. It supports cloud-only, hybrid and on-premise scenarios.

So, now that we have a source code management system in place, our source code is centrally managed and validated. But how do we move our applications from one environment to another? Let’s have a look!

In our ABAP-based system, moving changes throughout the system landscape is pretty straightforward. SAP Transport Management System (TMS) will be configured to determine what the system landscape looks like. With that in place, a transport with all recorded changes is released in the development system and imported into the destination systems.

Unfortunately, in cloud-based systems like Business Technology Platform, there is no such thing as automatic recording of changes which can be moved from one environment to another. However, we do have a handful of options on how we can deploy our applications to different environments.

The first and most straightforward option is to deploy each application manually in each environment in the landscape. We don’t recommend this option. It’s prone to human error. It gives the developer the option to skip the central source code management system and al its configured tests.

The second option is to extend your Continuous Integration (CI) server pipeline with Continuous Delivery (CD) steps. These additional steps will create a deployable package of the application after all configured tests have been successfully executed. The resulting package can either be deployed manually or automatically from within the pipeline. The only downside of this setup is that the system landscape needs to be configured for each repository - basically for each application.

For Business Technology Platform specifically, there is a third and last option: using Business Technology Platform Transport Management in combination with Continuous Delivery steps in your pipeline. Business Technology Platform Transport Management allows the configuration of system landscapes in a way similar to what we’re used to in our on-premise ABAP-based systems.

After the deployable package is created in our Continuous Delivery pipeline, instead of deploying it directly to Business Technology Platform, this package will be added to the import queue of Business Technology Platform Transport Management.

Packages in the import queue can either be imported manually or an automatic import can be scheduled. It’s important to notice that Business Technology Platform Transport Management also supports Business Technology Platform Integration, which makes it even more interesting to integrate it into your landscape.

If you start developing on the Business Technology Platform, you should pay this topic due attention, because a good application lifecycle management strategy may save you a lot of time and money in the long run. The earlier you set up a good strategy, the easier the implementation.

Are you thinking of moving applications to Business Technology Platform? Or are you already running applications in Business Technology Platform? Are you seeking assistance to get a good application lifecycle management strategy in place? Feel free to contact us. TheValueChain can guide you through all the steps.