Skip to Content

Release Management in SAP –A structured Approach -Part1

In my past experience spreading over a decade I have seen that Release Management has been a topic of great concern and also a topic of great admiration if everything falls in place otherwise uncontrolled changes in the form of released work packages can destabilized an entire set up of working environment in production and also help desk set up becomes helpless. In couple of my projects  a structured approach  saved the day for myself and  stakeholders which is being shared  and hope that this may help  in giving an insight to some of the practices in the area of release management. I also agree that scope of improvements may also exist in this shared approach.On the onset  of an implementation project during Pre GOLIVE we conducted a series of workshops and discussion with all key stake holders and established that Release Management is necessary to ensure that all change applied to a Production environment is implemented in accordance with a planned schedule which incorporates both the programme and business requirements.  Each year, a Release plan will be published which defines the windows of opportunity in which changes may be introduced into the production environment. The plan will allow for significant releases for the introduction of major new functionality or new country go-lives, as well as smaller and more frequent releases for minor changes and production fixes.  The plan will take into account business cycles, as well maintenance windows. The plan is a living document that reflects the next 12 months of change to be applied to the Production environment. In accordance to these workshops we established some of the guiding principles in general as well for system synchronization which proved to be handy in long run. 

General

  • The published annual Release Schedule will apply to SAP and related applications portfolio. (The long term intention is that the entire application portfolio will adhere to one Release Schedule and way of working.)
  • The Release Schedule will be communicated to and followed by the business in order to minimize disruption and to allow for forward planning.
  • The business will plan for a complete system outage during the published release windows.
  • The Release Manager will be responsible for managing a Release from definition through to the Production environment.
  • Release Scope will be nominated in advance and fixed at a specific checkpoint in the Release schedule.
  • Releases will be approximately quarterly and bi-monthly.  Emergency Releases will be approved by exception only. This will include any country go-lives, etc.
  • Release components which do not successfully pass the Release checkpoints, will automatically be moved to the next available planned release.
  • The scope of all releases will be planned and approved within the defined timeframes. A cut-off date will be defined at which point the Release will be frozen and no future changes will be allowed.  The scope of the release will then be progressed through the release lifecycle.
  • The Release Manager has the overall final signoff on the movement of releases into Quality and Production. A Release will not be moved into Quality or Production unless it has passed all of the approval criteria. 

System Synchronization

  • All Releases will go everywhere to all environments across the landscape.
  • Quality and Production environments should be kept in sync to provide Production support. 
  • Quality will be refreshed from Production periodically prior to regression testing, dependent upon the release content.
  • Quality and Production remain the same, except at the start of Regression Testing phase when Quality receives all the transports for that release.
  • Regression Testing should be is kept as optimum as possible so that Quality and Production have a delta for a short period of time.
  • Changes are applied sequentially along the path, one environment after another.
  • Transport Requests are imported in release sequence.
  • Transports do not cross system or Support Pack release level.
  • All environments must be on the same Support Pack.
  • Emergency Transports (Hot Fixes) are promoted out of sequence in exceptional cases i.e. Production Support break-fixes.

In blog Release Management in SAP –A structured Approach –Part2 http://weblogs.sdn.sap.com/cs/junior/view/wlg/22805 We emphasized on change types, release types and there definitions.

In blog Release Management in SAP –A structured Approach –Part3 http://weblogs.sdn.sap.com/cs/junior/view/wlg/22814 we foccussed  on Release Management process ,various inputs coming from  different processes such as change management etc.

In blog Release Management in SAP –A structured Approach –Part4 http://weblogs.sdn.sap.com/cs/junior/view/wlg/22816 we foccussed on Release Management Governance,roles and responsibility,and Communication.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.