Overview of Information Technology Infrastructure Library (ITIL) for IT Services

Information Technology Infrastructure Library (ITIL) provides good practices for every field of running IT service. The main goal of Release Management is to set up processes that ensure that service transition proceeds smoothly. All transitions should be scheduled and planned in advance.

Deployment and Release Management are tightly connected (in fact ITILv4 describes those topics together). The main goal in here is to prepare procedures and processes that will ensure delivery of the services described by Service Design on the level that meets the stakeholders` requirements.

In terms of software development it usually means that we will be able to deliver software (and install) having given set of developed and tested capabilities within given period of time. Release and Deployment Management focuses on packaging, testing and finally deploying into production.

Such organized approach helps to minimize the risks related to introducing changes into production environment, helps to keep all the parties up to date. It additionally helps to track if (and when) given set of requirements has been met.

Basic concepts

Release unit set of infrastructure bundle of products or part of one product that is usually released together. Usually in case of a product release unit is an entire application as a result all functionalities of the app should be tested together before moving to production. For other kind of services different strategy may be used – there are few questions that should be asked when choosing release units: how long it takes and how time/resources consuming would be preparing given release of the given unit, how well the given piece is separated from the rest of service – usually it is advised to use ‘naturally’ existing fragmentation.

There are multiple strategies of defining Service Design Process (SDP), following descriptions try to distinguish them and thus help to choose the correct one:

  • Big Bang strategy means that we will perform update of service for all users at once – such way of introducing changes in general is more dangerous as errors that have not been discovered during tests will be visible to every user. On the other hand it helps to keep the product consistent and limits efforts related to supporting and sustaining older versions etc.
  • Phase based update splits update into few steps in each step, users are being rolled out following plan established a priori. That way of introducing changes gives us opportunity to introduce some ‘last minutes’.

Of course strategy that are possible to apply depend on the type of the service for example in some cases there is no way to limit the range of changes because all users use the same shared environment – in such case we can introduce changes incrementally introducing changes step by step in order to control the update.

Pushing or pulling changes

Push strategy assumes that we will enforce the update start delivering the changes to the user once, pull strategy is different – we made the change available to the user but it’s up to him when to make us of it. Of course it is possible to come up with a mixed solution (which in fact may be recommended) i.e. some critical updates are pushed but the rest, which is not so important is made available to download.

Sometimes the type of service may not allow to implement deployment by pushing.

Manual or auto prepared releases

Decision of release and or deployment automation should be made in the design phase. Finding a right balance is a trade off. On one hand release automation requires maintaining and testing but on the other hand it saves the time and resources spent on preparing each release and usually is less error-prone.

The common approach consists of creating and maintaining 3 environments:

  • Development – in that phase requested change is being implemented, usually it is good to additionally implement solution review step that precedes deploying the change in test environment – that will significantly improve quality of introduced changes.
  • Testing
  • Production (live) – any changes performed in that environment should be scheduled and tracked.

Each change before being deployed needs to go through all the environments. Process of proceeding a release to the next environment should be well defined. ITIL 2020 advises that, for some set of Minor Changes, simpler, not involving Release Management process might be introduced in order to avoid wasting resources on trivial procedures.

Average rating / 5. Vote count:

No votes so far! Be the first to rate this post.