This is an excerpt, you will find more detailed descriptions in the book.
If an organization is to be responsible for an object, regardless of whether it is a building, a train or an IT service, then detailed knowledge of the object is required as well as complete control of the object’s component parts.
The Release Management process is the IT organization’s way of obtaining knowledge about and checking the component parts in the objects for which it is responsible. The process is the organization’s chance to get to know the object, develop knowledge, document procedures and test functionality before the object goes live for delivery to the business. In the worst case, skipping this step means that the IT organization is responsible for operation and maintenance of an object about which it has insufficient knowledge.
The release process comprises all resources that are required to build, test, package and establish a release in the production environment, and also to ensure all parts specified in the design package before transition to IT operation. Examples of what can be included are:
- Physical or virtual resources such as servers, network equipment and databases
- Applications and other software
- Training of staff or users
- Procedures and processes
- Agreements with the business and contracts with suppliers
A release planshould normally be drawn up for each change comprising the entire flow from development and testing to deployment and approval. To facilitate major projects and administration of applications, a release plan is prepared which corresponds to the entire project or the administration plan for the specific application. Transition can thus support methods, such as agile development for example, without entailing unnecessary administration for each sub-release.
With, for example, application development, a plan is established within the framework of the development project which is approved and financed by the purchaser. A change record is subsequently registered in the Change Management process for the entire project plan and a release plan is drawn up for the entire project. Each sub-release in the project is subsequently managed as a separate deployment.
A release unit is the release’s smallest component part. It might be a server, an application or an update of an application. An example of a release unit is a sprint release from application development, but it can also be a complete virtual server. The scope of a release is different on each occasion. The release plan should therefore state which release units are included in the specific release.
The release units which are built in order to be deployed together are put together in a release package. It might, for example, be a combination of hardware and software which must be changed at the same time or documentation and training as a supplement to a new application.
A release is the overall designation for that which is tested and deployed in the IT environment at the same time. A release can consist of a single release package or several different release packages which are not directly dependent on each other.
In the agreements with the business, the IT organization can indicate a number of predetermined dates on which planned changes are to be implemented. This facilitates internal planning, at the same time as it regulates the business’s level of expectation during these dates. Each release windowis managed as a release and has a specific release plan for each occasion.
A release model can be created for recurrent releases of a similar type. It describes the steps through Release Management and functions as a template for a release plan. It is often beneficial for IT organizations with a large number of systems that are updated to create a release model which is used by all administration groups.
The model can also be used by suppliers with the aim of making the collaboration faster and facilitating planning. The model contains:
- Overall structure for a release
- Start and end criteria
- Environments for development and testing
- Roles and responsibilities for components included
- Information model
- Version management
- Templates for change schedule
- Procedures and tools for documentation activities
There are four main activities in the Release Management process:
- Plan– Produce a release plan for the entire release
- Develop and test– The release package is built and made ready for deployment
- Deploy– The release package is deployed in the production environment
- Evaluate and close– Experience is compiled and evaluated for future improvement proposals