DevOps Models for SAP BTP

[gniranjan]

SAP Business Technology Platform witnessed further growth and momentum in 2021 with double-digit growth YOY in terms of revenues and customer adoption. “Rise with SAP” is a strong driver of this adoption with Dufry International, Yamaha Corporation, SoftBank, Office Depot Mexico, and Reckitt recent entrants into the BTP the world.

(Source: Q3 2021 Earnings Report from SAP)

SAP Business Technology Platform (BTP) is a PaaS offering from SAP positioned as the foundation for intelligent enterprise with integration and extensibility across SAP and Non-SAP solutions.

As customers continue to ramp up application development on SAP BTP, it is important to envision modern development and DevOps practices at work to fit SAP technology into the enterprise quality and compliance toolchain, which is often maintained in silos at present due to the monolithic nature of transport management.

Some of the key aspects of modern development practices include (if not all) the following:

• Version Control Integration


• Code Review and Pull Requests


• Unit Testing Code Coverage


• Security checks


• Automating packaging and deployments


• Automated test suites designed for Sanity testing, regression testing, and long-running tests.

.. In a nutshell, it is an opportunity to bring every aspect of compliance, quality, and security as shift-left into the Software Development life cycle of SAP applications.

From our experience with the customers using SAP BTP, here are two DevOps Models that will continue to be nurtured and used by customers going forward are shared here.

 

 Model1 : MTAR + CTS

DevOps for SAP BTP with MTAR and CTS

Assign the User Story

A user story/incident is assigned to a Developer from Jira /ServiceNow / Azure DevOps.

The Developer works in the business app studio / IDE to complete the development of the change and pushes it to the feature branch in the GIT Repository.

Validate and build the change

1. Fetch the changes from the feature branch in GIT Rep


2. Create MTAR bundle based on YAML definition


3. Run unit tests and generate Code Coverage


4. Prepare the changelog based on the GIT commits in the branch for code review


5. Update the user story in Jira /ServiceNow / Azure DevOps


6. Run static code analysis and prepare the report.

Approvals and Deployments

1. The MTAR build is deployed to Dev Subaccount.


2. Dev teams do their testing and approve for QA


3. The GIT commits can be uploaded to SAP Cloud Transport management as transports.


4. Using Pull commands, the changes can be fetched SAP CTMS into the QA subaccount.


5. Once the QA sign-off is done, RFC can be created from ITSM tools like ServiceNow for production deployment


6. Cloud Transport is imported into the production subaccount.

Benefits

• Teams are used to working with transports.


• No changes can be made to transports giving binary model deployments.

Challenges

• Retrofit challenges in the case of multiple landscapes will exist.


• Not flexible enough to dynamically add new systems into the landscape ( Eg. Hotfix )

Model2: MTAR + GIT Merge

DevOps for SAP BTP with GIT and MTAR

Assign the User Story

A user story/incident is assigned to the Developer from Jira /ServiceNow / Azure DevOps.

Validate and build the change

The validation of the change and building of the MTAR artifact are same as discussed above.

Approvals and Deployments

1. The MTAR build is deployed to Dev Subaccount.


2. Dev teams do their testing and approve for QA


3. The user story feature branch is merged with the Master


4. The change is again validated and a new MTAR is built from Master.


5. The MTAR bundle created from Master is deployed to the QA subaccount.


6. Once the QA sign-off is done, RFC can be created from ITSM tools like ServiceNow for production deployment


7. The MTAR bundle is deployed into the production subaccount.

Note:  A variant of this can be to maintain one branch for every subaccount to achieve the highest level of isolation of the change.

Benefits

• MTAR based deployments and is in line with modern deployment models


• GIT merge helps to visualize conflicts better compared to retrofit.


• Since the deployment is entirely from GIT, adding a system to the landscape is relatively easy.

Challenges

• GIT merge and conflict resolution is cryptic for beginners and needs some learning curve.

 

Back-up and Rollback Strategy

With version control becoming the source of truth, backup and rollback of application changes can be done much more efficiently.

Teams can prepare the list of objects that are being deployed, take a backup of them from the Master branch before doing the GIT merge, and create a custom MTAR bundle or a transport that can be deployed back in case of any rollback.

Conclusion

SAP Business Technology will bring modernization and cloud benefits to SAP development. The above DevOps models can be further fine-tuned in the coming years based on developer community feedback.

 

[tuliovargas]

Hi Gattupalli, I really appreciate your post!! Congrats.

[nils-lutz]

We have implemented such a pipeline (Model2 in your post) in the past and it feels like a breeze if you are already familiar with Git

We moved the Code Review to the Dev and Feature branches in Azure DevOps and are using the approval features to control the merge to the Main branch and the deployment to BTP.

[gniranjan]

Thank you Mr. Tulio

[gniranjan]

// We moved the Code Review to the Dev and Feature branches in Azure DevOps.

Perfect Shift left strategy and something that we can visualize now better with modern platform like SAP BTP.

[rahulpippalla]

Hi Niranjan,

Great Blogs..!!

Blogs on SAP DevOps are rare and would like to see more.

[gniranjan]

Thank you Rahul.

[former_member752487]

Hi Niranjan,

I apprieciate your blog post.

Thank you,

Larissa

[gniranjan]

Thank you Larissa.

[kevin_hu]

Most commonly seen scenarios at this moment. Great Summary.

Hope to see more usage and adpotion in the community of the newly offered CI/CD pipeline + CTS + Process Automation + Alert Notifications integrated with ServiceNow, for example...and also with a broader coverage of not just mta applications, but also the other artifacts such as from integration suite.

[gniranjan]

Absolutely Kevin.

[former_member810117]

Hi niranjangattupalli

Thanks for the blog..

We are in the processing of CI/CD pipeline for one of the customers using Azure DevOps <--> SolMan ChaRM <--> SAP BTP applications (through cloud TMS for transport migration). Customer is insisting to use SAP Cloud Connector to connect on-premise SolMan system. Did you come across this scenario by any chance? Please advise your view on this.

BTW, did you implement any pipelines for model 1 or model 2 scenarios? For example, 1) creation of change, 2) creation of transport, 3) Code quality check using one of tools (SonarQube) after the developement,  3) Migration of the change(transport) to consequent changes, 4) Merge code (branching). Please let me know if any specifics are there.

Thanks in advance

[gniranjan]

Hi Sudhakar,

I can share the implementation details of both the models setup for our customers ( using ReleaseOwl) , if you DM your information.

Happy to help !!

PS: I am part of ReleaseOwl.

Thank you.