Release management
The Release Management (including release management , English spelling release management ) is a process, originally from the experience of product management of the software industry deduced that the bundling of configuration changes to a release or release package and their proper integration into the infrastructure ensured. Release management means planning and executing the release, from the idea or the first requirements to reaching the end user. It thus interacts between change and configuration management . It is part of the ITSM or theITIL - Service Management .
The task of release management is to ensure that an expected requirement for a change in a process with an acceptable risk can be successfully implemented in the required time. Adjustments in the business area to constantly changing external requirements require permanent reconfiguration of the systems that control the underlying processes. At the same time, in a complex environment, this evolving process of permanent reconfiguration of systems increases the risk of disrupting vital business processes through misconfiguration, influencing them in an unforeseen manner or bringing them to a complete standstill. A company justifies the use of release management by reducing the sometimes considerable costs caused by any process disruptions that can be caused by necessary configuration changes. The task of release management is to reduce the risks of business process interruptions when changes to the configuration of existing systems are caused by poorly planned or insufficiently tested system configurations.
Release management tasks
The release management has the following tasks:
- Determination of the functional scope
- Determination of the exact schedule for a release release in coordination with change or product management
- Quality control to monitor compliance with the criteria that were defined as part of change or product management for a release creation
- Documentation of the scope and changes, in particular a description of the properties relevant for backward compatibility
- Management of the version history ( versioning ) to ensure reproducibility
Release requirement
Release requirements are first recorded by change management . The change management usually also formulates the 'use case' and also takes care of the approval process (depending on the risk relevance, sometimes quite complex). Then the actual task of implementing a change, i.e. the 'executive', is handed over to the release management. This often results in the opinion that release management is a sub-area of change management. However, according to practical experience from the ITIL area, release management is deliberately not a sub-area of change management. Companies that do not take this into account and integrate release management into change management will quickly find themselves in internal conflict situations of responsibilities in which the important elements of risk assessment, planning and quality control are usually out of balance. Thus, the release management also ensures that a release can implement the expected requirement with an acceptable risk in the required time. The current ITIL version 3 takes this into account and has therefore explicitly defined release management as an independent process unit.
Release planning
The planning creates the core framework, the actual blueprint of an entire release project.
Release decision
The release manager decides when a system can be released as a release for distribution. He must make sure that the system is free of serious errors, i.e. that it is reliable in production. In traditional software development , this is the case when the development process reaches the Release Candidate stage.
Risk analysis
Risks must always be compared with business perspectives. A residual risk is partially consciously accepted, e.g. For example, not losing the business advantage achieved by an earlier release date due to late releases with higher quality.
Quality control
The quality control of a release is one of the most important elements in ensuring the change objectives, i.e. the question
- what do you originally want to achieve with changing a configuration from a business perspective and
- does the result also match the requirements?
This is realized through appropriate test plans, through simulations and development and testing of strategies for emergency situations.
Release creation
When the pure development is finished, this does not mean a release at the same time. This often requires further steps:
- Creation of the configuration status, which includes all components
- Compilation and designation of both the source code and all data files
- Provision of configuration files, user manuals, technical documentation, ...
- Provision / distribution ( data carrier , e-mail, download , ...)
- Training and preparation of the employees who use the system
- Training and preparation of the employees who maintain the system
Release documentation
The documentation of releases is e.g. B. very important for later post-production or tracing of special releases for individual customers or platforms.
The documentation should contain a complete description of the entire system environment and the underlying system (programs, versions, documents, descriptions, instructions , ...) in order to simplify subsequent restoration.
DHL - Definitive Hardware Library
Archiving for the logistic management of the technical components of a company.
DSL - Definitive Software Library
Archiving for the logistical management of a company's software components. DSL became DML (Definitive Media Library) after ITIL V3 was released (May 30, 2007).
Certification
ISO / IEC 20000 release management as part of the ISO / IEC 20000 standard.