Published: April 25, 2008 | Updated: October 10, 2008
Once the changed has been built, tested, and reviewed for release readiness, it is time to release the change.
Figure 8. Release the change
Activities: Release the Change
The Release Readiness Management Review marks the end of the testing of a change. At this point, the process of releasing the change begins. Releasing the change coincides with the Deploy SMF in the Deliver Phase of the IT service life cycle.
The following table lists the activities involved in this process. These include:
Releasing the change and any accompanying site components into the production environment.
Stabilizing the release.
Getting final customer approval of the change.
Documenting the released change and communicating the impact to users.
Transferring responsibility from the project team that built the change to Operations and Support.
Updating the RFC and the configuration database.
Table 9. Activities and Considerations for Releasing the Change
Activities
Considerations
Release the change
Key questions:
Is the change stable enough to release?
Is the team ready to release the change to production?
Inputs:
Released change, including:
Solution deliverables.
Solution documentation.
Release plan
Output:
Released change
Best practice:
Make decisions about the release strategy early in the project, possibly in the envisioning or project planning phases, to minimize risk.
Stabilize the release
Key questions:
Does the team have a plan to monitor the solution during the quiet period? This is the period when the project team is no longer active but does respond to issues as Operations and Support escalate them to the team. Typical quiet periods last from 15 to 30 days.
Is the release change stable?
Have all issues found by testing and through pilot feedback been resolved?
Has user acceptance testing been done?
Inputs:
Test specification document
Master plan, including the test plan
Test scenarios and test cases
Lab environment
Interim builds, including:
Solution deliverables.
Documentation.
Issue-tracking database.
Issue-tracking policies and procedures
Outputs:
Release candidate
Pilot-ready release candidate
Best practices:
Use a formal issue-tracking system to track and report the status of bugs.
Document issue-tracking and reporting procedures during planning.
Define and agree on success criteria for testing the release candidate.
Do not release the candidate until the entire team signs off on its suitability.
Do not begin a pilot test until the project team, customers, and users all agree on the criteria for a successful result.
Get final customer approval of the change
Key questions:
Is the customer satisfied with the change?
Does the customer accept the released change?
Input:
Released change
Output:
Release sign off
Document the released change and communicate the impact to users
Key questions:
Have changes made to IT components during release been communicated and documented in the change log?
Has the team recorded in the change log any workarounds or requests for change submitted regarding the release?
Inputs:
Information about the change
Service map
Outputs:
Updated change log
A stable solution released into the production environment
A customer who is satisfied with and accepts the released solution
A solution that is successfully transferred from the project team to the Operations and Support teams
Best practice:
Clearly communicate the change to all interested parties.
Transfer responsibility to Operations and Support
Key questions:
Has the change solution been transferred successfully from the project team to the Operations and Support teams?
Has training been done to ensure that Operations and Support personnel are prepared to manage and support the new service solution?
Input:
Released change
Output:
A managed and supported service solution
Update the RFC and the configuration database
Key questions:
Has the RFC been updated to reflect any changes made from the original request?
Have changes made to IT components been recorded in the CMS?
Have any workarounds or requests for a change submitted in support of the release been recorded in the CMS?
Inputs:
Changes made in original request
Information about changed CIs
Outputs:
Updated RFC
Updated CMS
Best practice:
When a change is moved to production, update the CMS current state so that an accurate picture is available for problem analysis and other RFCs.
.jpg "Cc543243.image8(en-us,TechNet.10).jpg")