- SAP Managed Tags:
As my initial blog post series around DevOps with SAP BTP is already some years old, I thought it would be about time to come up with a new article - to reflect latest changes about how you can enable your teams to benefit from it for developing and running their apps on the platform.
DevOps is a key enabler for achieving high-level agility and quality in development projects – also in SAP enterprise environments. If you should be new to DevOps, the DevOps | SAP Community topic page does offer a lot of information.
Although DevOps is mainly a cultural approach, tools can help to foster agile development principles along the lifecycle of applications. In this article, I will sketch the setup recommended by SAP for agile development projects on SAP BTP, using corresponding SAP BTP cloud services and offerings. The platform does offer several different development approaches and runtime environments, so details of this setup might slightly differ per use case, but the goal is to offer a similar concept fitting for the most important ones.
The following figure outlines the recommended approach on the example of SAP BTP, Cloud Foundry environment:
Recommended approach to apply DevOps on SAP BTP
As most of the depicted SAP BTP cloud services are also part of SAP Build Code, this does also reflect the recommended approach around this offering.
Let's go through those four phases in the remainder of this article.
1. Set Up Continuous Integration
One driver of the agility and built-in quality that DevOps brings is the automation of large parts of the deployment pipeline. For this, a Continuous Integration / Continuous Delivery (CI/CD) pipeline is involved that automatically gets executed whenever your development teams do submit changes to their source code management system, to qualify them. The pipeline automatically performs certain actions along different stages, such as to build your changes and to test them on different levels. With this, it provides feedback to the developer on the quality of his/her changes:
So, the first challenge is to set up CI/CD for your SAP BTP development use cases. Here, SAP BTP does offer a two-fold approach:
- Option 1: Pipeline as a Service with SAP Continuous Integration and Delivery
- Opinionated, highly integrated setup that allows to benefit from agile methods without having to bring expertise
- Brings pipeline templates for typical SAP BTP development use cases, such as to develop a side-by-side extension using Cloud Application Programming model (CAP) or a compelling UI using SAP Fiori on Neo/Cloud Foundry/ABAP Front-End Servers; with this, it allows to come up with a running build, test and deploy pipeline for those SAP BTP specific use cases in minutes – where the pipeline can be configured completely via UI (configuration as code is optionally also possible)
- No need to build up and especially operate an own CI/CD infrastructure – only prerequisite: bring your own Git as source code management system
- SAP product, with direct support from SAP
- With this, addressing also those partners and customers that do not bring experience or that are looking for a CI/CD setup recommended and provided by SAP, reducing the overhead and cognitive load of their developers
- Option 2: Toolbox with open source offering project ‘Piper’
- Building blocks that allow you to build an own pipeline for SAP-specific use cases easier: pipeline templates (for Jenkins only), a library of pipeline steps (in Golang, which allows you to use them also for non-Jenkins CI/CD infrastructures), scenarios (end-to-end descriptions with sample code snippets), and Docker images you can easily add to your pipeline (example for usage with Azure DevOps)
- As it is an open source offering, there is no direct support provided by SAP – only community support, you have to create and then own your pipeline
- With this, the offering is addressing those partners and customers that need full flexibility and already bring expertise or infrastructure (or are willing to build it up and operate it) and now want to know how to best expand it also for SAP-specific use cases
2. Develop
This CI pipeline is then used by your development teams to qualify their changes – here, changes get pushed to a central source code repository based on Git, which then can automatically triggers a run of the corresponding pipeline via webhook. This pipeline run performs a build and executes automated test cases. The developer then gets informed about issues with the performed changes and can react on those directly. Also, compliance checks, such as for security flaws with used third-party libraries, can be tested as part of the pipeline run.
Of course, there are many frameworks available for automated testing – SAP Continuous Integration and Delivery service does provide an opinionated proposal for corresponding frameworks, which then have to be set up accordingly. If you want to use alternative frameworks, SAP Continuous Integration and Delivery allows to extend the predefined pipelines with scripting (for more information, see this blog post).
For the creation of the actual test cases, a step-wise approach is recommended, where you start with first test cases and then evolve by time, by adding additional cases, also based on the issues that come up later and on the latest compliance requirements you might face.
As implied above, the actual development process will slightly differ per development environment. For example, on Cloud Foundry, you might use SAP Business Application Studio (where you would benefit from a direct integration of SAP Continuous Integration and Delivery, allowing to set up and monitor corresponding pipelines directly from the IDE), on Neo SAP Web IDE Full-Stack and on SAP BTP ABAP development tools in Eclipse. Still, the general approach for these environments could be similar, as depicted above.
3. Deliver
When your teams come up with a qualified release candidate, they can either perform a direct deployment out of the pipeline (when all tests are “green”, a direct deployment can be triggered) – or you benefit from a standardized central transport and change management approach, using SAP Cloud Transport Management. The later is our recommended approach for most enterprise environments, where you normally want to have additional control of your production subaccounts.
The actual transport concept is quite similar to what you might be used to from development in on-premise and private cloud environments, with a centrally defined delivery landscape:
- With the option to control who is allowed to handle changes where (that is, on which SAP BTP subaccount),
- With a central log file for auditing,
- With the option to synchronize the propagation of changes from different environments (such as from private cloud/on-premise together with related cloud changes), where change and deployment management capabilities of SAP Cloud ALM or Change Request Management (ChaRM) of SAP Solution Manager could orchestrate SAP Cloud Transport Management service, in addition to orchestrating then also private cloud/on-premise transport mechanisms.
Still, here with the option to combine it on SAP BTP with CI principles, so that your development teams can benefit from tight feedback loops enabled by an automated pipeline, to verify single developer changes - while you still have full control for the propagation of those changes towards your production environment, with the automated hand-over from the pipeline into a controlled, centrally managed and pre-defined delivery landscape. Then to verify the release candidate, potentially consisting of changes from different environments and typically done with a manual confirmation.
SAP Cloud Transport Management service can cover more and more content types, such as:
- SAP Fiori content (in Neo and Cloud Foundry)
- CAP applications (in the form of MTA archives),
- Objects from SAP BTP ABAP environment,
- Content from SAP Build (SAP Build Process Automation, SAP Build Work Zone, …),
- App-specific content types, such as iFlows from SAP Integration Suite and Network Package content from SAP Analytics Cloud
- See the full list here
With this, you can establish a standardized transport management process for more and more development use cases around SAP BTP - with the option to integrate all those content types into your central change and delivery management process, such as provided by SAP Cloud ALM.
SAP Cloud Transport Management service is out-of-the-box integrated with SAP Continuous Integration and Delivery - just switch on the corresponding option of the Release stage:
It can also be integrated into other CI stacks via a step of the library from project Piper into third-party pipelines or open APIs (for example, see this blog post on using Azure DevOps with transports).
4. Operate
With SAP Cloud ALM, SAP is providing a central observability platform for all SAP products, including SAP BTP (in interplay with several local SAP-BTP-specific observability capabilities). To operate your apps on SAP BTP, you can therefore use its unified monitoring, alerting and analytics offering based on telemetry data exposed by SAP BTP (and other SAP solutions), to reduce the meantime to detect any issues. SAP is using OpenTelemetry as unified and open instrumentation approach for SAP BTP use cases, allowing you for example to instrument your custom apps for central observability.
For more information, see SAP Cloud ALM for Operations.
To resolve issues, you can then navigate from SAP Cloud ALM to the local expert tools on SAP BTP, to perform a use-case-specific root cause analysis. For example, from an error message in Exception Monitoring of SAP Cloud ALM, you could directly jump to SAP Cloud Logging service to perform a detailed analysis, for which the service stores and visualizes log files, metrics, and traces from your apps running in different SAP BTP environments.
For the execution of corrective actions on SAP BTP, events in SAP Cloud ALM could automatically trigger the execution of corresponding commands on SAP Automation Pilot. This service offers a low-code and no-code automation engine and brings catalogs of automated actions that you can use to compile the best-fitting command for automating your recurring DevOps-related tasks and for remediation of alerts from your individual SAP BTP applications.
This way, you can optimize your operation efforts and increase the resilience of your business scenarios.
In case you want to apply Infrastructure-as-Code principles based on an industry standard, consider to use the Terraform Provider for SAP BTP to automate provisioning, management and configuration of resources on SAP BTP.
Summary
SAP BTP offers a low-entry approach to verify the value a more agile development process can bring - also for your SAP applications. It does comprise highly-integrated DevOps services along the complete lifecycle - from CI/CD to development, delivery and operations, with a smooth integration option into SAP Cloud ALM, as SAP's strategic operations and central observability platform. SAP Cloud ALM allows the central operation of your holistic business scenarios spanning several environments. If you should have special needs or third-party frameworks already in use around DevOps, benefit from open APIs of the DevOps services of SAP BTP and of SAP Cloud ALM.
If you want to learn more, check out the information from the DevOps | SAP Community topic page and consider to take the learning journey Discovering DevOps with SAP BTP. If you want to try it out, all DevOps services are part of SAP BTP free tier, so the above setup can be experienced without charge. Otherwise, SAP Build Code is a good starting point as well, as it does comprise most of the DevOps-related SAP BTP services.
2 Comments
