DevOps with SAP BTP: Deliver & Change
This is an article in a series of blog posts, where I provide more details on the portfolio of DevOps cloud services around SAP BTP.
In this blog post, I plan to give further insights on the offerings for the Deliver & Change phase of SAP’s DevOps portfolio – for an overview of the overall offering and all categories, please see this blog post.
In the delivery phase, you want to propagate the increment (that is, the release candidate of your new app or a new version of an existing app) towards your production environment, so that your end users can start adopting it.
One straight-forward approach is to extend your Continuous Integration pipeline by Continuous Delivery, where the propagation of your increment gets triggered by the pipeline (automatically or with manual approval), if the result of the automated tests being part of the pipeline is as desired.
This is especially reasonable for cloud-native apps, but can also be used for enterprise apps, if the boundary conditions do not demand more control. To set up Continuous Delivery, you could apply Project “Piper” or use the SAP Continuous Integration and Delivery service, as outlined in the description of the Plan & Set Up phase.
Especially in enterprise environments and for more complex environments, operation teams appreciate the option to apply standardized change management processes also for the cloud artefacts of their company – to add transparency on the audit trail of changes (granting clarity on who perform which changes in which production subaccount and when). Also, change management opens up the door to synchronize cloud transports with on-premise changes, in case you should have hybrid apps with close interdependencies that you have to manage. Here, transport management options come in:
- For ABAP-centric and hybrid landscapes, where you might have already a management process for your on-premise changes in place, the enhanced Change and Transport System (CTS+) allows also the handling of changes based on Multitarget Application (MTA) archives in SAP BTP. In the on-premise CTS+ system, you model your cloud landscape and then control the deployment of content into your different SAP BTP accounts along transport requests. The setup of CTS+ for SAP BTP is described in How-To guides for both Neo and Cloud Foundry environments.
In short, this is our on-premise transport option and could also be a valid choice for cloud transport management, if you should have CTS+ already in use for on-premise and you only want to handle SAP BTP content in the form of MTA files (no other cloud content format is planned to be supported, also in the future).
- For cloud transports, we offer the SAP Cloud Transport Management service, as cloud offering that allows the transport of development artifacts (via MTA archives) and in addition of application content (such as from SAP Workflow service, SAP Fiori, or Business Logging) as central service – also both for Neo and Cloud Foundry environments and to and from other global accounts.
In short, this is our standard recommendation for cloud transports and would be the valid choice, if you target a cloud-based approach for transport management or if you plan to handle also other application content, no matter if provided in the form of MTA files or in another format.
Hybrid Change Management
For hybrid changes, both approaches (CTS+ and the cloud-based Transport Management service) offer the integration into change management processes running on SAP Solution Manager via Quality Gate Management (QGM) and Change Request Management (ChaRM). Prerequisite for the integration of SAP Cloud Transport Management is SAP Solution Manager 7.2 SP10. The overall high-level view and positioning is sketched in the following figure (not shown in the picture is the option to transport MTA-based changes in SAP BTP with CTS+ – however, MTA-based changes will stay the only cloud content type supported by CTS+ also in the future):
Combination of Continuous Integration & Transport Management
If you want to get the best of both worlds (with a combination of CI and transport management – also already depicted above), you can also consider to differentiate between:
- A development landscape, based on Continuous Integration principles and used to verify single developer changes by an automated pipeline and
- A delivery landscape, based on strict transport management rules (such as policies, schedules and roles) and used to verify release candidate versions, where propagation towards production is typically done with manual confirmation
The hand-over from the development landscape to the delivery landscape is part of the pipeline – for example, for SAP Cloud Transport Management service, you can use a scenario description and corresponding steps from the Project “Piper” step library to automate the hand-over of the fully qualified archive, as described in this blog post.
With this combined approach, your development teams can start easily, by using an automated pipeline, and come up with results quickly. Nevertheless, as soon as they come up with a release candidate, you can regain control of the changes especially towards the production environment with the then set up hand-over into transport and change management.
Result of the Deliver & Change phase should be your app being deployed to the production subaccount with the fitting amount of control of your production environment, so that the app can be used by your end users.
To make sure your app is now provided with the right availability and performance to its end users, continue with Monitor & Operate, the next phase in your DevOps adoption journey with SAP BTP.