【正文】 bining them into one release and deploying them together. The goal of the release management process is to ensure that all changes are deployed successfully into the production IT environment in the least disruptive manner. Therefore, release management is responsible for: ? Driving the release strategy, which is the overarching design, plan, and approach for deployment of a change into production in collaboration with the change advisory board (CAB). ? Determining the readiness of each release based on release criteria (quality of release, release package and production environment readiness, training and support plans, rollout and backout plans, and risk management plan). Within the MOF Changing Quadrant, the Release Management SMF is reliant on the Change Management and Configuration Management SMFs. Release management is embedded within the change management process and although the release is plete at the end of the release management process, a change review follows to ensure that the change element of the release was successful. Release management does the following: ? Provides a packaged release for all changes deployed into production and only deploys changes approved by change management. ? Needs change management to approve changes and track them throughout the release process. ? Ensures that, as changes are made, those changes are reported to configuration management for entry in the configuration management database (CMDB). ? Needs configuration management information to build and verify valid test environments in the development phase of the new release. ? Needs configuration management to assess the impact of changes to the IT environment and to provide a definitive store for the release package. 2 Introduction This guide provides detailed information about the Release Management SMF for anizations that have deployed, or are considering deploying, Microsoft174。 technologies in a data center or other type of enterprise puting environment. This is one of the more than 20 SMFs defined and described in Microsoft Operations Framework (MOF). The guide assumes that the reader is familiar with the intent, background, and fundamental concepts of MOF as well as the Microsoft technologies described. An overview of MOF and its panion, Microsoft Solutions Framework (MSF), is available in the MOF Service Management Function Overview guide. This overview also provides abstracts of each of the service management functions defined within MOF. Detailed information about the concepts and principles of MOF and MSF is also available at What39。 20xx operating system domain controllers. On receipt of the RFC, the release manager determines how many domain controllers are affected, where they are physically located, and the amount and type of memory that is required. The release manager also identifies any build or process documentation that refers to the amount of memory that should be installed in or ordered for a domain controller. The release manager also needs to understand the nature and scale of the changes to be made to each ponent in order to plan effectively and select the appropriately skilled personnel resources. The release manager may need to call on subject matter experts, technical specialists, thirdparty suppliers, and others to help perform this task effectively. Service Management Function 11 The release manager should capture and record in the change log all the information collected during this activity and decisions that are made as a result. To prehensively scope a release, the release manager can utilize information held in the CMDB to determine which technology ponents may be affected by the release. Even without using a CMDB, truly accurate pletion of this activity requires uptodate configuration information. This information needs to be presented in such a way that those involved in this activity can effectively plan the requirements of the release. The software and hardware inventory information reported by SMS can be used to provide the release team with a wealth of information about the target environment. Complex queries can be created to select Windows clients based on whether they meet specific requirements. For example, a simple query can be created to establish which Windows workstations meet the hardware requirements for running Microsoft Windows XP . Define and Prioritize Release The release manager oversees all change requests passed to release management from change management and is thus in a good position to assess how these changes should be moved into the production environment. In many cases, the release manager treats each RFC as a separate release project—with its own project plan, allocated resources, and implementation schedule. Treating each RFC as a separate release project keeps the project plan simple and minimizes risk to the production environment. Since only one of these projects is permitted to update a particular IT ponent at any one time, any related issues bee more apparent. A service pack upgrade to a Windows 20xx domain controller, for example, would normally be treated as a separate release project, with no other changes (to that server) permitted during the same time as the upgrade. Note that changes to other IT ponents in the production environment may be scheduled to occur at the same time. It may be preferable, however, to bine a number of different RFCs to form a single release project, especially if the RFCs make different changes to the same IT ponents and services. Making changes in this manner can often help reduce downtime and improve the use of resources available to the release manager. For example, an upgrade to the basic input/output system (BIOS) version of a server is approved by change management. The BIOS upgrade requires that the server be taken