release160management(编辑修改稿)

release160management(编辑修改稿)内容摘要：

Plan releases in line with requirements resulting from approved changes.  Build effective release packages for the deployment of one or many changes into production.  Test release mechanisms to ensure minimum disruption to the production environment.  Review preparation for the release to ensure maximum successful deployments.  Deploy the release in line with structured implementation guidelines. Key Definitions Backout plan. A documented plan detailing how a specific change, or release, can be undone after being applied, if deemed necessary. Change advisory board (CAB). The CAB is a crossfunctional group set up to evaluate change requests for business need, priority, cost/benefit, and potential impacts to other systems or processes. Typically the CAB makes remendations for implementation, further analysis, deferment, or cancellation. Change manager. The role that has overall management responsibility for the change management process in the IT anization. Deployment. The introduction of a release into the IT environment. Release. Within the context of MOF, a release is any change, or group of changes, that must be incorporated into a managed IT environment. These changes are packaged into a single release. Release manager. The role that is responsible for managing the activities of the release management process for the IT anization. For releases with large and plex scopes, the release manager forms a team to manage the release activities. The release manager selects the team members and assigns team roles and responsibilities. Release package. The processes, tools, technologies, and documents required to move a release into production. Also, all of the ponents of the changes that are contained in the release. Request for change (RFC). The formal change request, including a description of the change, ponents affected, business need, cost estimates, risk assessment, resource requirements, and approval status. 4 Processes and Activities This chapter provides a detailed discussion of the processes and activities that occur in the Release Management SMF. Process Flow Summary Release management involves five major processes necessary to successfully plan and deploy authorized releases into an IT infrastructure. The following process flow diagram (Figure 1) identifies the major release management processes. Figure 1. Release management process flow This highlevel overview can be further divided into a number of detailed tasks and process flows, which together provide a prehensive blueprint for the release management process. These are described in the following sections. The release management process begins once change management approves a request for change (RFC) and any solutions pertaining to it have been developed and are considered pleted for release into the production environment. 8 Release Management Release Planning The first step in the release process is the creation of a plan identifying the activities and the resources required to successfully deploy a release into the production environment. The process flow leading to the creation of this plan is shown in Figure 2. Figure 2. Release planning process flow The first stage of any project planning activity is to determine what tasks need to be done, when they need to be plete (timescale), and what their priority is in relation to other tasks. Only when these issues are fully understood can the release manager draw up a detailed plan of activities and assign appropriate resources to the project. In the Release Management SMF, the release manager role is responsible for building a release (project) plan for each RFC approved by change management. Service Management Function 9 When an approved RFC is passed to release management, the release manager establishes which IT ponents and services need to be changed in order to implement it. The release manager also determines the type and nature of the change in order to plan effectively and select the most appropriate resources in terms of strategy, requirements, and cost, taking into account any agreedto service levels. To perform this activity, the release manager may call on technical specialists, subject matter experts, thirdparty suppliers, the infrastructure planning advisory board, and others who may have a clear idea of the requirements associated with the change. Having established what needs to be done, the release manager then decides how to release those changes into production. It may be appropriate, for example, to treat the RFC as a simple singlerelease project, with its own project plan and allocated resources. On the other hand, it may be beneficial to bine the changes from one or more RFCs to form a more plex release package. Once the release is defined, the release manager assigns a release priority and formulates a release plan that describes the tasks and activities required to deploy it into production. Allocating resources to each activity and factoring in resource availability enables the release manager to work out (for the first time) whether the release can be deployed by the required date. If the release is not possible given the available resources, it may be necessary to review other ongoing project mitments and consider changing priorities to facilitate progress on this release. Note that the release manager may need to discuss this with change management to ensure they have a full picture of the business priorities and any other changes that may be dependents or prerequisites of the release. With an agreedon project plan, the release manager can build and document a release strategy describing how to prepare the anization to accept the release, what risks it poses to the production environment, and the manner in which it can be removed from production should it fail to meet。