Many SAP clients are faced with the dilemma of aligning the deployment of changes in their Frontend layer (SCP, Cloud Applications, etc) with the changes in their Backend systems (ERP, S/4, BW, etc). The main problem arises from integrating native deployment tools in the Cloud world such as Jenkins with the tools specific to the SAP world such as ChaRM.
In this video we will take a look at how to deal with the problem of deploying changes, in heterogeneous environments in the SAP world.
Different possibilities for using DevOps methodologies are beginning to materialise within the SAP world, thus abandoning traditional deployment by means of TMS. However, the use of DevOps Tools still has open elements such as dealing with custom objects, therefore, at Novis Euforia we incline towards an intermediate phase where both types of tools will coexist: with frontend tools such as Jenkins and the traditional backend ABAP tools like ChaRM.
It’s common to encounter changes which need to unify deployments in a cloud frontend layer with changes in the traditional SAP backend layer. The problem we find is that in frontend layer changes, the deployments are controlled by cloud applications, whereas in the backend layer the changes are managed with the SAP TMS. We have managed to combine Jenkins with ChaRM, which enables us to control the global deployment from one single point, integrating all deployments in an approval workflow within ChaRM. By doing so, we will avoid the deployment of cloud tools being carried out directly in production.
Key points in Jenkins and ChaRM Integration
Control in deployment
Avoiding errors with independent uploads to production
Integrating cloud tools and traditional tools
DEMO and example
In the example scenario offered in the DEMO video, the developer is working on an application to deploy it in SCP Cloud Foundry. The developer has a private Git repository and can make changes and versions of the application in the same. You may identify with him 🙂
The GIT repository can also be different and centralised and have a central administrator, or be used by developers independently.
Once the developer has tested a change or a new version in its local Git/Jenkins/SCP environment, that change is repeated in the central Git repository.
As with Git, the project has a central Jenkins request which is managed by an administrator, to guarantee the security and consistency of configuration. This central Jenkins may be configured for several scenarios of deployment towards SCP. One of these is direct deployment, which can be configured flexibly.
We will see how the DevOps world merges with change management in SAP projects, integrating the deployment of Jenkins with ChaRM in Solution Manager.
When integrating ChaRM with Jenkins the developer decides that the new version of the application can be passed on to change management in SAP. To do so, the respective Jenkins pipeline is executed, which goes through the following stages:
- Preparation.
- Generating the MTAR file.
- Creating Solution Manager in ChaRM from a transport request within a change document.
- Including the MTAR file as an attachment to the transport request.
At this point the scenario can be configured so that the developer can either release the request generated in ChaRM, or pass it on to the normal flow of change management via the central administrator.
In the change document, we can see that the transport request has been generated with the changes made front end, at this point we can continue the flow of deployment to production, bearing in mind that the necessary approvals are made in each system deployment with the standard ChaRM mechanisms.
At Novis Euforia we offer DevOps services like the ones seen in the video. Contact us to get more information in a short session of less than an hour.
