Skip to end of metadata
Go to start of metadata

Deployments

In SAP Solution Manager 7.2 "Deployments" succeed the template / implementation project concepts as applied in global roll-out scenarios known from SAP Solution Manager 7.1. Deployments allow to define deployment master which can be rolled-out. To manage deployments it is recommended to have

  • a "Deployment Authoring Solution" for managing the deployment master and its releases, and a 
  • a "Operational Solution" where all operational processes are managed. 

It is not recommended to create one solution per roll-out or entity.

The functions below describe the basic activities relevant to manage content deployments. Even though the examples below show mainly processes, the same mechanisms also apply to library objects. For instance if a customer wants to deploy shared libraries and localized processes, he can do so. All this is is possible. Deployments can be used to cope with rather complex process landscapes. 

Before you start work with deployment you should make yourself familiar with the Branch basics and best practices.

To see how deployments work with Logical Component Groups Branches and Sites please see here.


Building a deployment master

Given one wants to define a deployment master then a deployment release was created in a deployment authoring solution. The branch setup for a release follows the standard SAP Solution Manager branch setup best practice. The production branch then represents the ready for roll-out deployment version.

When a customer wants to roll-out a deployment he would use the content export functions to create an export file.

Do not flag the "Map to origin" checkbox.

Multiple deployment master releases can be managed in a single deployment authoring solution. The release n+1 "production" branch (with its development, design and import branches) would be created as child to the "production" branch of the release n branch.

Even if the underlying release n branch was changed the user could recognize differences between the releases by looking at the change status.

Multiple deployment master releases can be managed same time and exported and deployed independently.


Roll-out a deployment

All deployments should be managed in one central operational solution. There is no need and it is also not recommended to manage different deployments in independent solutions.

It is recommended to create (at least for processes) a folder used to separate the different deployments. The operational solution can accommodate multiple deployments which may are on different deployment master release levels.

A new deployment is always recognized under a given name.

Update a deployment

To update an existing deploy one could take an updated content file and import it while having an existing deployment selected beforehand. Now the system would update the existing structures accordingly.

It is recommended to follow the best practice branch structure. Using the import branch ensures that proper change status is visible indicating how the existing elements were changed.


Re-export a deployment

After roll-out a deployment might be changed to adjust the processes to the local requirements. The changes might be relevant for the other roll-outs as well. For this reason the local changes should be re-exported for integrating them back into the deployment master.

The re-export can be achieved by ticking the checkbox for "Map deployment to origin" so that you can indicate the original source of the deployment. With this re-export file the local adjustments can be re-integrated into the deployment master.


Roll-in a deployment

After one created an re-export file, local changes can be integrated (roll-in) into the deployment master by importing the file.

It is recommended to follow the best practice branch structure. Using the import branch ensures that proper change status is visible indicating how the existing elements were changed.

  • No labels