Release Management

What is a Release? A Release is a collection of authorized changes to an IT service.

Release Management is responsible for the implementation of all new and existing Hardware and Software releases (along with the related documents) into the live (operational) environment, under the controlling processes of Change Management and Configuration management. This process is concerned with protecting the live environment from any disruption and the Release Management activities are usually performed under the supervision of the Change Manager.

Releases can be classified as:

  • Major Software Releases and Hardware Upgrades – This usually contains large amounts of new functionality and overrides all preceeding minor releases and upgrades.
  • Minor Software Releases and Hardware Upgrades – This usually contains small amounts of new functionality and overrides all preceeding emergency releases and upgrades.
  • Emergency Fixes – usually contains fixes to a small number of issues.

All changes are released as “Roll Outs“. A Roll Out includes distributing all the Configuration Items to wherever they are used. This can be done in many ways, for example: by internet, email, remotely or even by sending them on CDs. But when there are large releases to be rolled out over a vast geographical and cultural area, the use of automated scripts are a great help. However these scripts might need passwords to activate them.

Release Management has to maintain traceability of all the releases. We need to know where a particular version has come from and what are the changes it contains.

The Release Management process covers the following three areas:

  • Development area.
  • Release Management’s own pre-production area.
  • Operational environment (live/production area.)

Migration from one area to another is subject to results from reviews, tests and other relevant quality checks.

Before a Release is Rolled Out into the live environment, Operational and Customer Acceptance tests are carried out. Operational tests ensures that anything that goes into the live environment is supportable, maintainable and robust. All existing and planned Backout Plans should also be fully tested.

The Contents of each Release is decided by Change Management but the Release Management team is always kept fully informed.

Hardware and Software Releases go through the following stages before they are Released into the live environment:

  • Distribute.
  • Build or Rebuild in the Live environment.
  • Implementation.

It is important that each of these stages are carried out accurately before it progresses to the next one.

Release Management is also responsible for:

  • DHS – This is the Definitive Hardware Store. It is a secure location or a number of locations where authorized versions of all hardware spares (Configuration Items in the live environment that exist in the CMDB) are stored.
  • DSL – This is the Definitive Software Library. Again, this is a secure location or a number of locations where copies of all authorized versions of software CI are stored. (CI stands for Configuration Items). It can also be defined as a Physical library or repository where master copies of all software versions are stored.

Information about the DHS & DSL exists in the CMDB (Configuration Management Database) and Configuration Management is responsible to keep it always updated.

Adequate protection/security should be provided to both the DHS and DSL against eventualities like floods, earthquakes, fire and of course theft. In case of the DSL, it should also be protected from viruses, data corruption etc.

Release Unit: A Release Unit is the portion of the IT infrastructure that is normally released together.

Release Type: There are three Release types which are as given below:

  • Full Release – In a Full Release, all components of the release unit are built, tested, distributed and released together. This is suitable for major changes and is very expensive.
  • Delta Release – In a Delta Release, only those components that have changed since the last release are distributed. This type of release is best suited for fixes and emergency changes and is less expensive.
  • Package Release – A Package Release is a group of Delta/Full release(s) which are released simultaneously. This type of release is suitable in situations where changes in one system may require changes to another.

Release Identification: Each release has to be identified. Usually, a numeric format is used. The specific release identification policy is generally decided by the Release Manager, after consulting with the Change Manager and the CAB. Example: A new application can be assigned an ID like v. 1.0 and a a later, minor release with some changes to it’s components can be identified as v.1.1. There is really no limit to the number of such levels that can be used to identify each release.

Roll Out Types: Releases can be rolled out in any/or a combination of the following ways:

  • Big Bang Roll-outs – where all sites in the enterprise receive the releases simultaneously.
  • Phased Roll-outs – where all sites receive some functionality at the same time and the remaining functionality at a later time.
  • Pilot Roll-outs – where a single site receives all the functionality at one time, ahead of the others.