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.
Purpose
The main purpose of the Release Management process is to establish changes in the IT environment without disturbing the existing production of IT services and also ensuring effective management of new services in connection with transition to Operation.
This takes place through all start-ups ensuring that:
- Release plans are drawn up together with stakeholders
- Release packages are developed and tested so that they function together with the rest of the IT environment
- The change corresponds to the requirements for availability and functionality
- Knowledge is developed and documented
- Deployment takes place according to plan and relevant procedures
- Deviations which arise are documented and managed
- Services that have already been deployed are disturbed as little as possible
Scope
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
Value for the business
The Release Management process supplies a value to the business through:
- Establishing changes more quickly, cheaply and with less risk
- Taking less time for new services to achieve the operational objectives in the business
- The regulated establishment process facilitating traceability
Release Plan
A release plan should 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.
Release unit
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.
Release package
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.
Release
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.
Release window
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 window is managed as a release and has a specific release plan for each occasion.
Release model
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
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
Plan
The scope of the planning depends on the size and complexity of the release that is to be established in the IT environment. The release planning is a part of the overall Transition phase, where the Change Control Board (CCB) approves or rejects the release plan. For major changes, this takes place in project form where the project’s steering group approves the release plan as a part of the project. For releases which comprise development of software, the IT organization’s development model for this step can be beneficially used.
The plan should contain as a minimum:
- Scope
- Activities
- Name and contact details for those who will be performing function tests and approving the different steps
- Administrator/technical analyst responsible for the release
- Time plan
- Cost
For major releases there is usually a complete design package. Besides this, the plan should also contain:
- Establishment plan – an overall plan for the deployment which includes information about users, physical locations affected by the installation, documentation, training etc.
- Pass/fail-criteria – Each step in the process should have defined criteria for whether to proceed or not
- Development and test plans – Needed to describe the steps and the method used for development work and also to ensure test of functional capacity and benefit for the business based on the objective set in the design phase
- Development and test environment – A controlled environment that is separated from the production environment
- Planning of release package – Content, structure and installation sequence
- Pilot – A group or department which tests the final release
- with the aim of investigating establishment activities and functional capacity in the new or changed service
- Financing – A budget for the entire release should be drawn up.
Development and test
Development and test contains the following sub-elements:
- Documented procedures – It should be simple for a development project to find and use procedures which describe how to access internal resources and components from external suppliers
- Release package – Documented and standardized procedures should be in place which ensure the quality and reuse of the design of the release package
- Establish development and test environment – The capacity to simply set up new, controlled test environments is a success factor in the Release Management process
- Functional test and pilot – Functions are tested on an ongoing basis throughout the development phase to ensure that development is proceeding in the right direction. It concludes with a pilot where the functional capacity is tested by a limited group in the business
- Service simulation – A simulation can be performed for new services with the aim of testing all the activities in the service which create value for the business in as realistic an environment as possible
Deplyment
Deployment contains the following sub-elements:
- Plan for deployment – The activity prepares the business and concerned parts of the IT organization for the establishment
- Evaluation of the target group – If it is a major release, the target group for the establishment in the business should be evaluated as the roll-out progresses. The result of the evaluation constitutes the basis for improvements to the detailed installation plan
- Detailed installation plan – Detailed planning of the start-up with activities and resources. Any risks in connection with the start-up are also identified here.
- Early life support – The release process is responsible for new services until such time as the IT operation has approved the change in the Change Management process
Evaluation and close
The following is checked during the evaluation:
- Were knowledge transfer and training sufficient?
- Has all feedback from users been documented?
- Are all known errors and temporary solutions documented?
- Have we achieved the conditions for approval?
- Is the change ready to be handed over to the IT operation?
- Is there anything in the Release Management process which needs to be improved?
Documentation
The following documentation should be available within the framework of Release Management:
- Release policy
- Release plans
- Establishment plans
- Development plans
- Test plans
- Procedures for test environment
- Procedures for deployment
Relationships with other processes and functions
The Release Management process has links to many other processes. The most common are listed here:
Trigger
The first part of the Release Management process is triggered through a change being approved for planning, development and testing. The second part of the process is triggered through a release being approved for deployment.
Input
The following inputs are needed for the process:
- Approved change record
- Design package
- IT policy including guidelines for hardware and software
- Purchasing procedures
- Documentation regarding current services
- Release models
- Development and test environment
- Method for test
Output
The following outputs are generated by the process:
- New, changed or removed services
- Updates of status to Change Management
- Updates of change schedule to Change Management
- Information regarding changes to the service catalogue
- New or updated service documentation
- New or changed agreements
- Packaged and version-managed installation package
Measurement
This is how the Release Management process can be measured:
- Number of releases which meet the expectation for cost, time and quality
- Number of releases which cause incidents
- Number of releases which are not approved by the IT operation in connection with transition
Challenges
The following elements require specific attention when implementing the process:
- Coordinating the Release Management process with other methods that are used for application development and administration
- Ensuring that all projects and subcontractors use the procedures for the Release Management process
- Understanding the risks present in connection with deployment
- Facilitating a culture where the staff share knowledge in the form of documentation
