Neven Zitek I’m sure that I’m not the only witness of the “instant service deployment” practice, which is most noticeable in a MS Windows® environment where software used for service delivery (Active Directory, file sharing, e-mail, etc.) is providing system administrators with easy-to-use installation wizards. These methods of software installation have been proven, and are so helpful that everyone expects software to run out of the box; therefore, deployment has to be performed almost the minute software has been installed. I understand that most (if not all) system administrators will tend not to agree with me, but please note that this article is not about system administration practice (or its critique), but about service management practice. I’m well aware of many installation and post-installation checklists performed in order to confirm that software has been successfully installed and configured, but from a service management point of view – that just isn’t enough.
ITIL Release and Deployment Management is a very important process for the service lifecycle, and there are many things I’d like to share with you, which may be too long for a single blog post. With that in mind, I’ve decided to make it a multi-part article, a miniseries if you like. Make sure you stay tuned for the next couple of weeks in order to find out what makes Release and Deployment so important. Welcome to the saga from a galaxy not so far away – Part 1.
General principles and policies
It should go without saying, but allow me to point out that time invested into planning for release and deployment will result in many benefits later on: a) faster change implementation with minimum costs, b) assuring that service meets business goals, c) improved implementation consistency, and d) production of auditable measurements through Service Transition. When planning a release of the service, note that release consists of Release Units – which are the set of new or changed Configuration Items introduced into the live environment either to implement an approved change or to implement a new service.
Definition of Release Unit content is up to you, but it may as well be defined within the organization’s release policy. Depending on business requirements, and overall service complexity, a Release Unit can be the service as whole, or it may consist of several Service Assets such as software or hardware. Having the complete service as a Release Unit could be required by a business, for critical applications, which will ensure comprehensive testing of the complete service. However, if a single component has to be changed, the complete service has to be tested before release – disregarding how minor the initial change was.
When deciding Release Unit levels consider the following factors: a) ease and amount of change required to release and deploy it, b) amount of resources required for build, test, and implementation, and c) complexity for interfaces between the single release unit and the rest of the environment. In Figure 1 a simple example of Release Unit levels has been shown based on e-mail service.
Figure 1: Simplified explanation of Release Unit level – based on e-mail service example
When defining the release policy, make sure that each service gets a unique identification, with a numbering and naming convention, as well as expected release frequency. The naming convention is totally up to you, and as for the numbering convention, good practice is to differentiate major, minor, function, and emergency releases by using the following identifiers:
- Type A – SERVICE_v.1 – major release that affects the service as whole, superseding all previous releases.
- Type B – SERVICE_v.1.1 – minor release that enhances or fixes parts of service, or affects service components, usually supersedes previous function of emergency releases.
- Type C – SERVICE_v.1.1.1 – release that affects a single function.
- Emergency – SERVICE_v.1.1.1.1 – change that is required in order to restore service.
Each release type should be correlated to expected release frequency and time window for release deployment. This will make future planning of release and deployment much easier, as well as ensure that planned service disruptions are not disrupting business, and are agreed within the SLA. For example, Type A releases could be planned quarterly, Type B monthly, Type C weekly – but only on weekends and holidays, and Emergency releases when required, with the highest level of authorization prior to deployment.
Service Testing
I can’t emphasize enough the importance of establishing the test environment and service testing. There are several different test categories that have to be performed before deploying and releasing the service:
Deployment Readiness Test – its purpose is to ensure all deployment processes, procedures and systems can execute deployment in a manner that will end up with new or changed service in the live environment.
Service Management Test will ensure that service performance can be measured, monitored, and reported once it is released into the live environment. It’s a very important part of service testing that often gets neglected.
Service Operations Test – its purpose is to check the ability of the service operation team to operate the service in production. From my personal experience, this part of testing is almost nonexistent, as the operations team is usually expected to be able to operate anything you throw in their general direction.
Service Level Tests are performed, in most cases, in conjunction with functionality tests, as functionality is often related to service level, and vice versa.
User tests will verify the end user’s ability to access and use the new service, as well as their ability to contact the Service Desk regarding the newly deployed service.
Service Provider Interface Test, as the name suggests, verifies interfaces to the service.
And, at the end, ITIL suggests the Deployment Verification Test in order to ensure that service capability has been correctly deployed for each deployment group or environment.
End of part one
In the following blog post(s) we’ll talk about Service Deployment and deployment options, benefits and possible drawbacks for each of them. As the process doesn’t end with deployment, there will be information about good practices such as Early Life Support, release review and closure.
Remember, everything in IT Service Management is change, and release is where change becomes visible. So make sure you stay tuned for Part 2.
To implement ISO 20000 easily and efficiently, use our ISO 20000 Documentation Toolkit that provides step-by-step guidance for full ISO 20000 compliance.
