【導讀】inferred.owners.What'sNew?

　　

【正文】 version of a server is approved by change management. The BIOS upgrade requires that the server be taken out of service (turned off) while the upgrade is being performed. A memory upgrade is also approved by change management (separate RFC) to take the server from 128 megabytes (MB) to 512 MB physical RAM. The addition of physical memory also requires that the server be taken out of service. If these two change requests were treated as separate release projects, the server would need to be taken out of service twice—with a subsequent impact on service availability. It would be better, therefore, to implement these two changes together as a single release and take the server out of service only once. Note that it may not always be possible to bine two or more RFCs into the same release project, either because of the type of changes being made to the IT ponents or because of the perceived risk to the production environment. Once the release manager determines the contents of a release, the release is assigned a reference number linked to the RFC number and the release manager tracks and records the progress of that release. As releases are used to implement changes, it is remended that RFCs and releases be tracked in the same, or patible, systems. Note The fact that an RFC has been allocated to a release (and the release reference number) should be recorded. 12 Release Management The technical needs of defining the scope of a release mean that any tool used on this function must cope with a range of release packages, covering everything from a single ponent up to a plex suite of interdependent ponents. The technology used within this space needs to be able to relate to the specific changes and construct release packages out of this. It also needs to have the ability to bine these packages into larger packages. Tools such as SMS can create software release packages that cover a large range of plexities. As release packages are created, distributed, and implemented, the release team needs tools to track the status of the release and return this information to the change management system. SMS, for example, provides a status system that provides information that can be extracted and fed directly into the CMDB. Plan and Schedule Activities Once the release has been defined and prioritized, the release manager constructs a release plan that identifies the tasks and activities required to deploy the release into the production environment. For small or wellunderstood releases, a release plan should contain all of the tasks and activities required to deploy the release into the production environment. For large and plex releases, however, the release plan may contain a number of tasks that simply indicate the duration and owner of a particular phase or stage, with the owner responsible for creating and resourcing a rollout plan to deliver that part of the release. If a release is to be deployed in Seattle, Cambridge, and Edinburgh, for example, the release plan may contain all of the tasks and activities required to roll out the release in Seattle, but not Edinburgh or Cambridge. The release manager may decide to delegate the task of planning and deploying the release in these two locations to locally based support staff as separate stages, since they have a detailed knowledge of the environment and can thus plan accordingly. Note that although the release manager may delegate responsibility for a part of the release to others, the release manager is still responsible for delivering the entire release, through all stages or phases, into production. In this respect, the release manager needs to agree on and then monitor the progress of all plans connected with the delivery of that release. The size and plexity of the release drives the selection of tools used to create and maintain the project plan. In planning a large and plex release, the release manager probably needs to use project management tools such as Microsoft Project, but this may not be necessary for smaller releases where a spreadsheet or simple document may be sufficient. Once the release plan is plete, the release manager may need to discuss it with the change manager and change advisory board, if appropriate, before selecting and assigning resources to specific tasks and activities. The necessity for this review depends on the size and plexity of the release, the number of resources required to implement it, and the perceived risks to the production environment. The release plan should be saved against the release reference number, and the change log for each RFC in the release should be updated to indicate that the release plan is now plete. Microsoft Project is an ideal tool for planning medium to large releases since it provides the release manager with an accurate picture of resource requirements and utilization. Its use may be inappropriate for small releases. Service Management Function 13 Determine Release Team Composition and Roles For small releases, the release manager may be the only individual required to deploy them into production. For more plex releases, the release manager may need to assemble a release team to carry out certain tasks and activities of the release plan, or the release manager may appoint phase, or rollout, managers to manage a specific part of the release process. A test manager may be appointed, for example, to manage the release during testing. If additional resources are required, the release manager identifies and selects individuals with the appropriate levels of skill and experience. In some cases, it may be necessary to obtain resources from thirdparty panies if internal resources are not available or do not have the required level of expertise. Note that release team members not under the direct control of the release manager may b