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.