This is an article in a series of blog posts, where I provide more details on the portfolio of DevOps cloud services around SAP Cloud Platform.
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” and SAP Cloud SDK offerings, as outlined in the description of the previous 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 Cloud Platform. In the on-premise CTS+ system, you model your cloud landscape and then control the deployment of content into your different SAP Cloud Platform accounts along transport requests. The setup of CTS+ for SAP Cloud Platform 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 Cloud Platform content in the form of MTA files (no other SAP Cloud Platform content format is planned to be supported, also in the future).
- For cloud transports, we offer the SAP Cloud Platform 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 Cloud Platform Workflow, 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 Platform 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 Cloud Platform with CTS+ – however, MTA-based changes will stay the only SAP Cloud Platform 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), 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 Platform 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.
Finally, if you should face further boundary conditions where Continuous Deployment does not fit (for example, if you have a large number of subaccounts or many own apps to handle, or for a provider/consumer scenario), we are also working on a central deployment management service, which shall grant insights on the deployments in your overall landscape (with history, app inventory and analytics), the holistic management of parameters for the respective boundary conditions (policies & schedules, roles & permissions, pre- and post-deploy activities) and the orchestration of the underlying deployment and delivery infrastructure and services.
Result of the Deliver & Change phase should be your app being deployed to the production subaccount, so that it can be used by your end users.
To make sure your app is provided with the right availability and performance, continue with Monitor & Operate, the next phase in your DevOps adoption journey with SAP Cloud Platform.