How to implement DevOps for SAP Cloud Platform: 4 best practices

Source: techtarget.com

A successful implementation of DevOps for SAP begins with understanding several best practices. Here are four to get you started.

Whether a DevOps implementation is only on the SAP Cloud Platform or is a hybrid approach with the platform as one part, it’s important to know how the unique aspects of the SAP Cloud Platform play into a DevOps strategy.

DevOps aims to make the development process more agile and efficient, while reducing the risks associated with change. It is a set of processes, technologies, and development and operational practices that have been adopted to varying degrees in much of the technology industry. Today, many SAP development teams are starting down the DevOps path, and teams working on the SAP Cloud Platform are no exception.

A DevOps implementation needs to be tailored to the development and operational platforms that admins use. Here are four tips to implement DevOps for SAP Cloud Platform.

1. Break out to shared DevOps toolchain when possible

Use an enterprise-standard Git repository if you have it, rather than SAP Cloud Platform’s Git repository support. The same advice applies to continuous integration tools, such as Drone and Jenkins; Agile management tools, such as Jira and Azure DevOps; and monitoring tools.

For teams that aren’t familiar with the tools used in the rest of the enterprise or for companies that have not adopted this type of DevOps toolchain, it is tempting to just use the SAP Cloud Platform tools. But doing so can have long-term costs in terms of unnecessary lock-in and limited features. For example, the Git repository infrastructure SAP Cloud Platform provides lacks most of the features of GitHub Enterprise, Bitbucket, GitLab and Azure DevOps, and it can also be unnecessarily complex to access from outside of the SAP Cloud Platform environment.

2. Get agnostic about development tooling

When a carpenter goes to a job, they bring their own tools. So, why do we require skilled developers to use enterprise-standard tooling to do the job? Mandatory use of enterprise development tooling has real costs in terms of ramp-up time and accessibility, but they are costs that IT pros have been paying without question for a long time in the SAP world.

Some DevOps tools need to be shared. Version control, ticketing systems and build systems come to mind. However, those tools should have standard interfaces that allow developers to connect using their tools of choice. WebIDE should be the default, but don’t require your developers to use it. Do the work to put infrastructure in place around SAP Cloud Platform to enable developers’ freedom. The good news is if you have already broken out to shared DevOps toolchain as suggested above, then you are nearly there.

3. Use subaccounts for tiered landscapes

One thing a lot of customers struggle with is which of the many abstractions available to use for tiered landscapes. Should development, QA and production environments be different applications, different HANA spaces or different subaccounts? The answer is you should use separate subaccounts for different environment landscapes. This can result in a surprising amount of infrastructure duplication, because if you are using the HANA database, you may need to run three separate HANA instances for a three-tier landscape.

To help cut down on this duplication, think about whether you can use your DevOps infrastructure to remove a tier. For example, if you are using the Cloud Application Programming Model (CAPM), do you really need a development tier? Or, can developers do local development using the CAPM Node.js modules and a local SQLite database?

4. Use SAP’s proprietary tools where appropriate

SAP does have many proprietary tools available in the SAP Cloud Platform that can provide a lot of value. Should you use them, or stick with shared infrastructure that is perhaps not as well-suited for job at hand? The answer is often both. Maybe SAP Mobile Services is just what you need for offline applications. Or, maybe you have a bunch of ABAP developers that are itching to provide value in a cloud environment, and the ABAP environment for SAP Cloud Platform is perfect for you. Or, maybe Cloud ALM, Translation Services or one of the many Leonardo machine learning services are just what the doctor ordered.

Figure out how to integrate those services into your shared DevOps toolchain, processes and development practices in a way that aligns with the rest of your organization’s approach. Sometimes, this means wrapping those services in abstraction layers to enable local development and testing. Other times, it means building small extensions to your DevOps toolchain to accommodate these services. And there may be magical moments when the services are well-designed for integration into your existing practices and slot in with no extra work.

As with so much else, the biggest tip of all is to learn the details and then take the time to zoom out and consider the big picture, ensuring the decisions you make align strategically to create long-term value for your business.