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.

Continuous Delivery

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, such as in the form of change transport and management. 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.

For example, the SAP Continuous Integration and Delivery service offers a release stage for the SAP Cloud Application Programming Model pipeline and both SAP Fiori pipelines that allows a direct deployment to a Cloud Foundry space resp. a Neo subaccount:

Transport Management

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 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 – also beyond MTA) 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. In addition, SAP Cloud Transport Management is the basis to handle SAP BTP changes with change and deployment management capabilities of SAP Cloud ALM (as described here).
• 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 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).

Hybrid Change Management

For hybrid changes, both approaches (CTS+ and the cloud-based SAP Cloud 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):

SAP Cloud Transport Management service is also integrated into change and deployment management capabilities of SAP Cloud ALM (as again described here).

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.

If you are using SAP Continuous Integration and Delivery service, you can let the pipeline directly trigger an automated upload of your qualified changes to SAP Cloud Transport Management service, as part of the Release stage of many pipeline templates:

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 potentially also change management.

Also, you have the choice to select fitting approaches for each product, depending on its need for transport and change management.

Result

Result of the Deliver & Change phase should be the deployment of your qualified app/changes to the production environment, using the required amount of control of your production environment offered by a direct deployment by the pipeline or the involvement of transport and change management. The app deployed to the production environment can then be accessed 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.