Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
moritzgysler
Product and Topic Expert
Product and Topic Expert
1,974

Update: April 10, 2024

This blog post will help you understanding how release management in SAP Cloud ALM supports you in orchestrating your release of changes to production. Release management is focusing on the deployment of changes and can be used in conjunction with the project timeboxes.

Define your Deployment Plan

In the Projects and Setup application you can define your custom deployment plans in the Deployment Plans section to streamline the planning of your deployments to production systems. One Deployment Plan contains several timeboxes called Releases. One project can only have one Deployment Plan assigned but the Deployment Plan can serve several projects.

Define Deployment Plan.png

Picture 1: Define Deployment Plan

Assign deployment plan to project.png

Picture 2: Assign Deployment Plan to Project


Deployment Plan as Cross Project Timebox

Since one Deployment Plan can be assigned to several projects it makes sense that the project timeboxes are defined in relation to the overarching release. This means a project sprint plan can be aligned with the Releases of the assigned Deployment Plan. In case we do have Release per month, e.g. a bi-weekly sprint schedule could fit in order to deploy after each second sprint. The Timelines view in the Cross-Project Analysis application provides a combined view on releases and sprints.

In the following picture we can see Release 2 in conjunction with Sprints 1 to 4.

Releases and Sprints in Cross-Project Analysis.png

Picture 3: Release and Sprint in Timeline view


Releases to Stay on Top of your Go-Live Activities

Releases in a project can be assigned to requirements to indicate a planned release of the fulfilled requirement to production. Based on the Releases assigned to a requirement you are able to plan the implementation of related user stories with sprints. Here the gantt chart view provides a good overview.

The actual release to production is planned on feature level. This leads to a simplification by decoupling of implementation and deployment planning. Completing the implementation of user stories does not necessarily lead to the fact that new functionality is deployed to production immediately. The end date of a Release can be seen as the go-live date.

Releases can be assigned to features in order to actually plan your go-live to production.

Release on feature.png

Picture 4: Release on Feature


You can easily figure out the features to be deployed to production by filtering on the status and the release of features.

Bundling via Release.png

Picture 5: Bundling via Release 


Conclusion

Utilizing Deployment Plan and corresponding Releases offer you an easy way to plan your implementation of requirements and the deployment of the corresponding features. By aligning your release schedule with your sprint schedule you are able to plan your implementation properly. The actual planning of your deployment to production is done on feature level hence the feature with the latest Release and thus with the latest planned go-live date is decisive for the actual go-live date of the requirement it is assigned to.

Looking forward to receiving feedback. For latest updates and notifications you can follow me by clicking @moritzgysler.

1 Comment