Loading

Release Management Metrics


What are Release Management Metrics?

It is a process that includes planning, designing, building, configuring and testing of hardware and software releases to ensure defined set of released components. In addition, release activities also include planning, preparing, scheduling, training, documentation, distribution and installation of release at user's location. Release management is a part of software engineering, which focuses on monitoring activities like development, testing, deployment and support of software releases.

The entire process of release management is handled by a team of experts who are well versed with the approaches of project management and also have a keen observation towards technical details of the software development life cycle.

If attention is not paid to a project's key areas, then deployment of an application could become a risky venture. A typical release management includes a list of metrics that are essential to assess the quality of a project. Following is a list of release management metrics that are used to assess whether it has met with Total Release Downtime.

  • Estimated Release Downtime -When the product is about to release, if there is a need to update the database or migrate to larger datasets, the team needs to capture a release downtime in the timeline. The time required by the team during the release is recorded before the release begins.
  • Actual Release Downtime -After the release is over, the actual amount of downtime consumed by the system is recorded. The deviations between the actual and estimated downtime is noted for future reference in order to plan releases even more systematically and accurately.
  • Root Causes for Unplanned Release Downtime -If there occurs a situation of unexpected downtime which was otherwise not anticipated, the responsibility of determining the root cause of such a scenario lies on the project manager. A record of such a kind of behaviour should be recorded to avoid any future discrepancies.
  • Unnecessary Release Downtime -Few projects are released repeatedly over many months and years. A software project's release should ideally be stable and not release in a sequence. Some projects are more stable than others.
  • Release Priority and Type Metrics :

    Different types of releases require different levels of quality assurance processes. Following are a few such types :

    • Epoch Releases :These kind of releases fall under the category of architectural transition. For instance if an organisation has its own e-commerce system that needs a complete transition from an old platform to a latest one. The releases that cater to such changes are termed as epoch releases. The coordination of among all departments is a quintessential activity and consumes a considerable length of time.
    • Major Coordinated Releases :These kind of releases require good participation from all the departments as the release spans across multiple platforms and applications. For example, an existing e-commerce website endeavours to integrate new ways of generating invoice or order fulfillment.
    • Minor Coordinated Releases :This type of release caters to few minor upgrades in the system within the organisation, such as upgrading to a completely new database driver.
    • Major isolated releases :When an application update is confined to a single application development team and needs to check whether the application interface is working as before , such an activity is known as major isolated release. Such releases generally involve less risks and may seek the assistance of other QA teams to get involved in the testing process.
    • Minor isolated Releases :This relates to a minor bug fixture and requires least amount of planning prior release.
    • Emergency production patches :As the name suggests, an emergency patch can be called for at any point of time for any kind of bug. An emergency patch could be simply rectifying a typing error or addressing a feature issue.

    Each of the aforementioned release types are based on priority levels, that is, those releases that involve less amount of amendments or least risk are addressed post fixing the more critical ones. For measuring the release types, one must adherer to the following types of release metrics :

  • Number of releases by release types and number of releases by release priority : Listing every release according to priorities assigned to them.
  • Total time spent by release type(days) :An assessment needs to be made with regard to the types of releases a team is involved in and the possible risks associated with it. This metric also keeps track of the major as well as isolated releases. The idea is to keep a track of the length of time required to handle the entire process.
  • Time spent by release priority(days) :This method takes into account the number of days required to address an issue based on its priority level. A constant monitoring of the level of priority assigned to handling risk activities should be done to ensure that the team is not stuck at the same emergency level.
  • On-time Delivery Metrics :

    • List the number of releases delivered by an application on scheduled time
    • List number of releases delivered on schedule on the basis of priority
    • Cumulative number of days by which an application's release has been delayed
    • Note the root causes of delay in delivery
    • To observe and list the reasons due to which few releases are mostly delayed