Release Management with SAP Cloud ALM

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 Release Plan

In the Projects application you can define your custom releases in the Releases section to drive a deployment plan to production. One release contains several timeboxes called Release Versions. One project can only have one release assigned but the release can be assigned to several projects.

Define release

Assign release to project

Release as Cross Project Timebox

Since one release 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 release versions of the assigned release. In case we do have release versions per month, e.g. a bi-weekly sprint schedule could fit in order to deploy after each second sprint. The Gantt Chart view in the Tasks application provides a combined view on release versions and sprints.

In the following picture we can see release version “Deployment 06 / 22” in conjunction with sprint “Sprint 14 / 22”.

Release version and sprint in gantt chart

Release Version to Stay on Top of your Go-Live Activities

Release versions in a project can be assigned to requirements to indicate a planned release of the fulfilled requirement to production. Based on the release versions 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 version can be seen as the go-live date.

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

Release version on feature

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

Bundling via release version

Conclusion

Utilizing Release and corresponding Release Versions 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 version 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 Moritz Gysler.