RELEASEMANAGEMENT-ITESCAM9发行管理itescam.doc

9 RELEASE MANAGEMENT 9.1 Goal of Release Management9.2 Scope of Release Management9.3 Basic concepts9.4 Benefits and possible problems9.5 Planning and implementation9.6 Activities9.7 Process control9.8 Relations to other processes9.9 Tools specific to the Release Management process9.10 Impact of New Technology9.11 Guidance for successful Release ManagementANNEX 9A Checklist to use when reviewing rollout plansANNEX 9B Sample Release Management objectives for distributed systems9.1 Goal of Release ManagementMany service providers and suppliers may be involved in the Release of hardware and software in a distributed environment. Good resource planning and management are essential to package and distribute a Release successfully to the Customer. Release Management takes a holistic view of a Change to an IT service and should ensure that all aspects of a Release, both technical and non-technical, are considered together.The goals of Release Management are: to plan and oversee the successful rollout of software and related hardware to design and implement efficient procedures for the distribution and installation of Changes to IT systems to ensure that hardware and software being changed is traceable, secure and that only correct, authorised and tested versions are installed to communicate and manage expectations of the Customer during the planning and rollout of new Releases to agree the exact content and rollout plan for the Release, through liaison with Change Management to implement new software Releases or hardware into the operational environment using the controlling processes of Configuration Management and Change Management - a Release should be under Change Management and may consist of any combination of hardware, software, firmware and document CIs to ensure that master copies of all software are secured in the Definitive Software Library (DSL) and that the Configuration Management Database (CMDB) is updated to ensure that all hardware being rolled out or changed is secure and traceable, using the services of Configuration Management. The focus of Release Management is the protection of the live environment and its services through the use of formal procedures and checks.Release Management works closely with the Change Management and Configuration Management processes to ensure that the shared CMDB is kept up-to-date following Changes implemented by new Releases, and that the content of those Releases is stored in the DSL. Hardware specifications, assembly instructions and network configurations are also stored in the DSL/CMDB.Release Management is often funded from major projects rather than being included in the cost of the normal service to Customers. Although there are costs associated with implementing Release Management, these are far less than the potential costs of not adequately planning, managing and controlling software and hardware Releases.9.2 Scope of Release ManagementRelease Management undertakes the planning, design, build, configuration and testing of hardware and software to create a set of Release components for a live environment. Activities also cover the planning, preparation and scheduling of a Release to many Customers and locations. Release Management activities include: Release policy and planning Release design, build and configuration Release acceptance rollout planning extensive testing to predefined acceptance criteria sign-off of the Release for implementation communication, preparation and training audits of hardware and software prior to and following the implementation of Changes installation of new or upgraded hardware storage of controlled software in both centralised and distributed systems Release, distribution and the installation of software. The main components to be controlled are: application programs developed in-house externally developed software (including standard off-the-shelf software as well as customer-written software) utility software supplier-provided systems software hardware, and hardware specifications assembly instructions and documentation, including User manuals. All deliverables need to be managed effectively, from development or purchasing, through customisation and configuration, through testing and implementation, to operation in the live environment.Figure 9.1 - Major activities in Release ManagementRelease Management should be used for: large or critical hardware rollouts, especially when there is a dependency on a related software Change in the business systems, i.e. not every single PC that needs to be installed major software rollouts, especially initial instances of new applications along with accompanying software distribution and support procedures for subsequent use if required bundling or batching related sets of Changes into manageable-sized units. Figure 9.1 outlines the major activities in Release Management and their position in the life-cycle of a Change. Configuration Management records should be updated during build and Release to ensure that there are trusted Releases that can be reverted to in case of problems. A Release should be under Change Management and the content and timing of a Release should be authorised in advance via the Change Management process.9.3 Basic concepts9.3.1 ReleaseThe term Release is used to describe a collection of authorised Changes to an IT service. A Release is defined by the RFCs that it implements. The Release will typically consist of a number of Problem fixes and enhancements to the service. A Release consists of the new or changed software required and any new or changed hardware needed to implement the approved Changes. Releases are often divided into: Major software Releases and hardware upgrades, normally containing large areas of new functionality, some of which may make intervening fixes to Problems redundant. A major upgrade or Release usually supersedes all preceding minor upgrades, Releases and emergency fixes. Minor software Releases and hardware upgrades, normally containing small enhancements and fixes, some of which may have already been issued as emergency fixes. A minor upgrade or Release usually supersedes all preceding emergency fixes. Emergency software and hardware fixes, normally containing the corrections to a small number of known Problems. There are normally dependencies between a particular version of software and the hardware required for it to operate. This will drive the packaging of software and hardware together to form a new Release of the service, along with other functional requirements. For example a new version of an application software system may require an upgrade to the operating system and one or other of these two Changes could require a hardware change, e.g. a faster processor or more memory.Release Management is concerned with changes to defined IT services. These can be implemented by rolling out a combination of new applications software together with upgraded or new hardware, or simply changes to the service hours or support arrangements.9.3.2 Release policy and planningThe main roles and responsibilities in Release Management should be defined to ensure that everyone understands their role and level of authority and those of others involved in the process.The Release policy covers Release numbering, frequency and the level in the IT infrastructure that will be controlled by definable Releases. The organization should decide the most appropriate approach, depending on the size and nature of the systems, the number and frequency of Releases required, and any special needs of the Users - for example, if a phased rollout is required over an extended period of time. All Releases should have a unique identifier that can be used by Configuration Management.A Release policy may say, for example, that only strict emergency fixes will be issued in between formally planned Releases of enhancements and non-urgent corrections.9.3.3 Release unitRelease unit describes the portion of the IT infrastructure that is normally released together. The unit may vary, depending on the type(s) or item(s) of software and hardware.Figure 9.2 gives a simplified example showing an IT infrastructure made up of systems, which are in turn made up of suites, comprising programs, which are made up of modules.Figure 9.2 - Simplified example of an IT software infrastructureThe general aim is to decide the most appropriate Release-unit level for each software item or type of software. An organisation may, for example, decide that the normal Release unit for its Transaction Processing (TP) services should be at system level. Such a policy means that each time a Configuration Item (CI) forming part of the TP service is changed, a Full Release of the whole of that system is normally issued. The same organisation may decide that a more appropriate Release unit for PC software should be at suite level, whilst the Release unit of a batch application should be at program level.The following factors should be taken into account when deciding the appropriate level for Release units: the amount of Change necessary at each possible level the amount of resources and time needed to build, test, distribute and implement Releases at each possible level ease of implementation the complexity of interfaces between the proposed unit and the rest of the IT infrastructure the disk space available in the build, test, distribution and live environments. 9.3.4 Release identificationReleases should be uniquely identified according to a scheme defined in the Release policy. The Release identification should include a reference to the CI that it represents and a version number that will often have 2 or 3 parts. Example Release names are as follows: major Releases: Payroll_System v.1, v2, v3 etc. minor Releases: Payroll_System v.1.1, v.1.2, v.1.3 etc. emergency fix Releases: Payroll_System v.1.1.1, v.1.1.2, v.1.1.3 etc. 9.3.5 Types of ReleaseFull ReleaseThe major advantage of full Releases is that all components of the Release unit are built, tested, distributed and implemented together. There is no danger that obsolete versions of CIs that are incorrectly assumed to be unchanged will be used within the Release. There is less temptation to short-circuit testing of supposedly unchanged CIs and of the interfaces from changed CIs to unchanged ones.Any problems are therefore more likely to be detected and rectified before entry into the live environment. The disadvantage is that the amount of time, effort and computing resources needed to build, test, distribute and implement the Release will increase. Although in some circumstances the testing of a delta Release (see below) may need to be as extensive as that for an equivalent full Release, the amount of building effort required to test a delta Release is normally less than for a full Release.Regression testing as part of the process of implementing a full Release allows a large number of components to be retested to ensure that there is no degradation in system function or behaviour.An example of a Full Release could consist of the complete Release of a new version of client desktop software, or client desktop hardware, or both.Delta ReleaseA delta, or partial, Release is one that includes only those CIs within the Release unit that have actually changed or are new since the last full or delta Release. For example, if the Release unit is the program, a delta Release contains only those modules that have changed, or are new, since the last full Release of the program or the last delta Release of the modules.There may be occasions when Release of a full unit cannot be justified. In such cases, a delta Release may be more appropriate. A decision should be made on whether delta Releases are allowed, and under what circumstances. There is no single correct choice. It is recommended that delta Releases be allowed, with the decision being taken case by case.In each case the Change Advisory Board (CAB) should make a recommendation, based upon all the relevant facts, on whether the Release unit stipulated in the Release policy is appropriate or whether a delta Release is preferable. In making its recommendation, the CAB should take into account: the size of a delta Release in comparison with a full Release, and hence the resources and effort required the urgency of the need for the facilities to be provided by the Release to the Users the number of CIs (below the Release unit level) that have changed since the last full Release - a very large number may enforce a full Release the possible risk to the business if compatibility errors are found in the Release (e.g. would it be preferable to wait for a full Release than to risk interface problems arising with a delta Release?) the resources available for building, testing, distributing and implementing the delta Release (e.g. if implementation is to be via non-technical staff, is it easier to implement a complete new Release than a delta Release?) the completeness of impact analysis information to make an informed and objective decision. Package ReleaseTo provide longer periods of stability for the live environment by reducing the frequency of Releases, it is recommended that, where appropriate and where the resulting larger amount of Change can be confidently handled without problems, individual Releases (full units, delta Releases or both) are grouped together to form package Releases. For example, Changes to one system or suite will often require Changes to be made to others. If all these Changes have to be made at the same time, they should be included in the same package Release.A package can, for example, contain an initial version of a new TP service, several new versions of batch programs, a number of new and initial versions of individual modules, together with the Release of a complete new desktop system (both hardware and software). Both full and delta Releases may be included.The use of package Releases can reduce the likelihood of old or incompatible software being wrongly kept in use. It can encourage organisations to ensure that all Changes that should be made concurrently, in different suites and systems, are actually made concurrently. It can also encourage organisations to test the interworking of these suites and systems fully.Care should be taken, however, not to exceed, in any particular package Release, the amount of Change that can be handled comfortably. When making a decision on what to include in the package, care should be taken to ensure that the full impact of all individual parts on each other part is understood and has been properly assessed.9.3.6 Definitive Software LibraryThe Definitive Software Library (DSL) is the term used to describe a secure compound in which the definitive authorised versions of all software CIs are stored and protected. This one storage area may in reality consist of one or more software libraries or file-storage areas that should be separate from development, test or live file-store areas. It contains the master copies of all controlled software in an organisation. The DSL should include definitive copies of purchased software (along with licence documents or information), as well as software developed on site. Master copies of controlled documentation for a system will also be stored in the DSL in electronic form.The exact configuration of the DSL that is required for Release Management should be defined before development commences. The DSL forms part of the Release policy or Change and Configuration Management plan for the organisation. The definition should include: medium, physical location, hardware and software to be used, if kept online (a DSL can simply be a secure tape library, if properly controlled and catalogued) - some Configuration Management support tools incorporate software libraries, which can be regarded as a logical part of a DSL naming conventions for filestore areas and physical media environments supported, e.g. test and live environments security arrangements for submitting Changes and issuing software, plus backup and recovery procedures the scope of the DSL: e.g. source code, object code from controlled builds and associated documentation retention period for old Releases of software capacity plans for the DSL and procedures for monitoring growth in size audit procedures procedures to ensure that the DSL is protected from erroneous or unauthorised Change (e.g. entry and exit criteria for items). Figure 9.3 - DSL and CMDB relationshipFigure 9.3 shows the tight relationship between the DSL and the CMDB. It also shows how the CMDB holds a secure record or index of the exact contents of each given Release.9.3.7 Definitive Hardware Store (DHS)An area should be set aside for the secure storage of definitive hardware spares. These are spare components and assemblies that are maintained at the same level as the comparative systems within the live environment. Details of these components and their respective builds and contents should be comprehensively recorded in the CMDB. These can then be used in a controlled manner when needed for additional systems or in the recovery from major Incidents. Once their (temporary) use has ended, they should be returned to the DHS or replacements obtained.9.3.8 Configuration Management Database (CMDB)The CMDB is updated and referred to throughout the Release Management process concurrently with updates to the DSL. It should contain the following information in support of the Release Management process: definitions of planned Releases, including the constituent hardware and software CIs together with a referenc