Release Management in SAP –A structured Approach –Part3

In the continuation of previous blogs

http://weblogs.sdn.sap.com/cs/junior/view/wlg/22804

Release Management in SAP –A structured Approach Part1

&

http://weblogs.sdn.sap.com/cs/junior/view/wlg/22805

Release Management in SAP –A structured Approach -Part2.

The scope of Release Management covers anything that is to be transported into the production environment.  This includes everything from incident, enhancement, portal content changes, master data changes, configuration changes, support packs, legal and regulatory changes, etc.  All inputs into the production environment must be scheduled into a planned release and managed through the release process.The inputs into the Release Process came from two primary sources – the Change Management Process and the AMS incident management process as depicted below

 

Process Flow

Release Schedule

The Release Manager will own, maintain, and publish the annual Release Schedule.  The Release Schedule will be defined and published at the beginning of the year.  The Schedule will be maintained via monthly Release Schedule meetings with relevant stakeholder in order to ensure that the schedule is up to date and adjusted where necessary.  Any adjustments will be published to the business in order that the business may plan as appropriate. It is critical that the business agree to and understand the implications of the Release Schedule.  The business must plan for a complete system outage during each release window.  Should a complete system shutdown not be required, the business may continue to use the system as per normal.

 

Release Plan

The Release Manager will also maintain the detailed Release Plan for each Release.  The Release plan will define the dates for the key activities and critical cut-off dates within each release.  For example, if a Release includes enhancements, EUT will need to be planned into the cycle.  Additionally, each Release will require country signoff of Regression testing.  Countries must plan the appropriate resource availability during the regression testing timeframe in order to review the regression results and to provide feedback. Components which do not pass exit criteria will not be moved to the next environment and must be moved to the Release for which scope is not yet frozen.

Key Release Management cut-offs include:

1. Scope defined and frozen
2. Build complete
3. Test complete
4. EUT complete
5. Regression complete
6. Migration to production successful

Keeping in view of release schedule and plan  we summarized the lifecycle of a release as shown below and this also added as an input to our release process later on

 

Phase	Purpose	Duration(Typical for e.g.)	Exits criteria
Define	To lock the scope of the Release and kick off the build.	0	Release scope frozen Requirements defined and signed off Functional specs updated and signed off Data impact defined and signed off
Build	To build and unit test the Release	15	Build and Unit Test complete Technical Documentation updated String Tests built or amended as appropriate
Test	To integration test the Release	5	String Test complete String Test signed off
EUT	To obtain business confirmation of the changes in the Release.	5	EUT complete EUT signed off by the business Confirmation of readiness to move to Pre-Production
Regression	To ensure that the new changes will not clash with the current live system	5	Regression Testing complete Regression Test results signed off by all live countries Support KT from project to AMS complete Confirmation of readiness to move to Production
Cutover	To release the approved changes into Production	2	Release successfully transported into Production System checks complete

Below is the overview of the Release Process steps

Process Steps

Activity	Responsible
Raise enhancement request	Requestor
Raise incident ticket	Requestor
Perform Impact Assessment and update Toolset	IT&S
Change Management Process	Change Approval Board
Close Request and Communicate	Change Approval Board
Identify Target Release	Change Approval Board Release Manager
Performance Detailed Release Planning	Release Manager
Capacity Planning	Change Approval Board AMS(Appl Maint & Serv)
Create & Clarify Tickets for Approval	AMS
Create Work Requests	AMS
Incident Management	AMS
Freeze Release Scope	Release Manager
Conduct Build	AMS
Conduct Test	AMS
Perform EUT	Requestor
Conduct Regression Test	AMS
Migrate to production	AMS
Pass	Release Manager
Assign to a Subsequent Release	Change Approval Board Release Manager

Raise Enhancement Request

All enhancement requests must be raised in service management Toolset. Toolset will be used to track, review, and approve/reject all enhancement requests.

Raise Incident Ticket

All incidents must be recorded in a service management system regardless of their source, or who identified them or what their status is (inclusive of support group findings / observations).

Perform impact assessment and update Toolset

Effort estimates will be produced for each request with System impact in line with the Change Management Process. Effort estimates will then be updated back into Toolset.

Change Management Process

All requests will be evaluated and reviewed by the Change Approval Board in accordance with the Change Management Process.

Close Change Request and Communicate

Once the request has been either approved or rejected, the request may be closed and the requestor communicated to with the results.

Identify Target Release

Step     Action

1. As part of the Change Management Process, a target release date will be identified for each approval and incident Ticket based on the published Release Schedule.
2. The Release Manager must review any existing planned scope for that release in order to determine if the change or incident can be incorporated into the identified release cycle.
3. The Release Manager must review the detailed release management planning in order to confirm capacity and which releases may still have open scope.
4. Input into prioritization effort.  

Perform Detailed Release Management Planning

Step     Action

1. Develop detailed Release plan for each release.
2. Consult existing release plans to determine capacity and whether scope has been frozen or not. 

Capacity Planning

Step     Action

1. Review existing capacity plans for AMS Teams.
2. Assessment of change and/or incident effort required and identified release window against existing capacity plans.
3. Update capacity plans.
4. Provide input into Change Management Process where necessary for re-prioritization.
5. Replanning may be necessary if demand exceeds capacity.  

Create & Clarify Tickets for Approval

Step     Action

1. Create service Management tickets for approved changes.
2. Track enhancement approvals through service management.

Create Work Request

Step     Action

1. Create a Work Request for each approved enhancement.

Incident Management

Step     Action

1. Manage incidents in line with the Incident Management Process as per the AMS Policy and Procedures manual.

Freeze Release Scope

Step     Action

1. Review the proposed scope (incidents + enhancement) for a particular release.
2. Escalate issues or prioritization requirements.
3. In order to pass the Freeze Release scope checkpoint, the following criteria must be met.
   1. Scope list defined
   2. Functional Specifications written/updated and signed off prior to release scope being frozen
   3. Detailed Data Requirements updated
   4. Budget approved, if required

Conduct Build

Step     Action

1. Manage build activities of defined scope and within release timeframe.
2. In order to pass Build checkpoint the following criteria must be met.
   1. Technical Specs written/updated and signed off
   2. Build and Unit Test complete
   3. String Test scripts available

Conduct Test

Step     Action

1. Execute string test activities of defined release scope and within release timeframe
2. In order to pass Test checkpoint the following criteria must be met.
   1. String test script executed and results signed off
   2. EUT scripts available

Conduct EUT

Step     Action

1. Execute EUT activities of defined release scope and within release timeframe.
2. In order to pass EUT checkpoint the following criteria must be met.
   1. EUT scripts executed.
   2. EUT results signed off by the business.
   3. KT to AMS Support complete.
   4. Release Manager Approval to migrate to pre-production.

Conduct Regression Test

Step     Action

1. Execute Regression Testing against incident fixes and enhancements within release timeframe.
2. In order to pass the Regression Test checkpoint the following criteria must be met.
   1. Regression scripts executed.
   2. Regression results signed off by all SAP live countries.
   3. Transports ready for migration to production.
   4. Updated Support procedures in place.
   5. Training to end users complete.
   6. Communications to end users complete.
   7. Change Management to end users complete.
   8. Release Manager Approval to migration to production.

Migrate to Production

Step     Action

1. Transport approved incident fixes and enhancements to production.
2. In order to pass Migration to Production checkpoint the following criteria must be met.
   1. Migrations to production successful.
   2. Production system checks successful.

Pass

Step     Action

1. Confirm whether the contents of the release have successfully passed the phase. Pass criteria for each phase is detailed above under the appropriate step.
2. If an enhancement or incident does not pass a phase, the object will be removed from the release and assigned to a subsequent release.

Assign to a subsequent release

Step     Action

1. Evaluate the extent of the rework required on the object, the next open release (when scope has not already been locked), the planned content of sequent releases, and consult the capacity plans.

Propose next release to Change Approval Board for approval 

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.