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.
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.
Picture 1: Define Deployment Plan
Picture 2: Assign Deployment Plan to Project
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.
Picture 3: Release and Sprint in Timeline view
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.
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.
Picture 5: Bundling via Release
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
21 | |
11 | |
10 | |
9 | |
8 | |
7 | |
6 | |
6 | |
6 | |
5 |