INTRODUCTION AND SCOPE
Once a new or changed service has been developed, we need to get it into the live environment, activate it and provide support while it beds down. Most commonly, people think about releasing new versions of software, but the concept applies equally to hardware and other components such as documentation. Indeed, major upgrades or new services will frequently involve combinations of all elements.
In the past, many issues were caused by development simply passing control to operations in a ‘clean-break’ move. Release and deployment management is concerned with making this a more phased and controlled process, including a period of early life support to ensure that everything is working as it should and can be used by the business.
Effective release and deployment processes require close interaction between development and operations, preventing the ‘throwing it over the wall’ syndrome so prevalent in the past.
PURPOSE AND OBJECTIVES
There must be clear plans that enable the business to align its activities with them and everyone must be satisfied with the mechanisms used.
Release and deployment management aims to build, test and deliver new or changed services successfully into the production environment within required timescales and with minimal disruption to existing services.
The purpose is to ensure that consistent and integral release packages are deployed in line with agreed policy and with plans agreed with the customers and stakeholders, and that this takes place under full and effective control. Any associated business and business process changes, including training and skills transfer, must be managed to take place in a timescale that is aligned with the release timetable.
The objective is to ensure that there are clear consistent plans that everyone understands and follows, that releases are managed efficiently and effec-tively through to deployment and use and that the new service and supporting 152
RELEASE AND DEPLOYMENT MANAGEMENT
systems are capable of being operated successfully and deliver the agreed service requirements (utility and warranty).
The scope of release and deployment management includes the processes, systems and functions required to package, build, test and deploy a release into production in accordance with the service design package (SDP). This includes handover to the service operation lifecycle stage.
Effective release and deployment management adds value by ensuring that custom-ers and uscustom-ers can use the new or changed service in a way that supports the business, and by delivering change faster and at optimum cost and minimal risk. Well-planned and well-implemented release and deployment can make a significant difference to an organisation’s service costs by minimising troubleshooting and rework.
BASIC CONCEPTS
The two constituent aspects of the process are release and deployment.
RELEASE
A release is one or more changes to an IT service that are built, tested and deployed together. A single release may include changes to hardware, software, documentation, processes and other components.
DEPLOYMENT
Deployment is the activity responsible for the movement of new or changed hardware, software, documentation, process etc. to the live environment.
A key concept is that of a release unit (i.e. the components of a service that are normally released together). A release unit typically includes sufficient components to perform a useful function. For example, one release unit might be a desktop PC, including hardware, software, licences, documentation etc. There might be standardised units for different roles or departments, or the desktop might be customised for each new recruit (where each instance is a separate release unit).
Another release unit might be a complete application, including IT operations pro-cedures and user training.
It is possible that a release will consist of more than one release unit. A release pack-age is one or more release units that are required to implement a new or changed service.
A release policy should be defined as part of the management control over releases.
In fact, it is unlikely that an organisation will have a single release policy; it is more
IT SERVICE MANAGEMENT
likely to have several, each covering one or more services. Each policy should cover Identification, roles and responsibilities, expected frequency, change acceptance criteria, automation, configuration verification, entry and exit criteria through phases, and handover from early life support to operations.
ACTIVITIES, METHODS AND TECHNIQUES
Figure 23.1 shows the four basic steps or phases in the release and deployment process.
Figure 23.1 Basic release and deployment process steps (Source: The Cabinet Office ITIL Service Transition ISBN 978-0-113313-06-8)
Auth
Auth
Auth Auth AuthAuthAuthAuthAuthAuth Change management
•
Release and deployment planning: Commenced once change management authorises the planning of a release.•
Release build and test: A release package is built and tested and then moved to the definitive media library (DML) in readiness for deployment into the live environment.•
Deployment: The release package is deployed from the DML into the live environment.•
Review and close: Did the release perform as expected and meet the antici-pated requirements?Whether a single RFC is required for the whole deployment process or a separate RFC for each step in the process is at the discretion of each organisation.
154
RELEASE AND DEPLOYMENT MANAGEMENT
CHALLENGES
The challenges that organisations will face when defining the right policies and implementing effective release and deployment include:
•
establishing standard performance metrics for all transitions;•
dealing with inaccurate project or supplier delivery dates;•
understanding all the stakeholder perspectives;•
understanding the risks;•
taking a pragmatic approach to the challenges of delivery.RELATIONSHIPS WITH OTHER SERVICE MANAGEMENT PROCESSES The key interfaces include:
Change management
All releases are driven by an authorised RFC.
Service asset and configuration management
Providing input for the components during the build and updating during the vari-ous phases of the release and deployment.
Incident management
Particularly during early life support when extra attention and resources may be required.
IT service continuity management
Continuity plans must be updated to reflect the new or changed service.
Capacity management
New resources may be required or loads on existing ones changed.
Service design coordination
Release and deployment contributes to the creation of the service design package and ultimately uses this as a key input to the release and deployment activities.
Transition planning and support
Provides a release and deployment framework and context.
METRICS
The following are some of the metrics for assessing the effectiveness of the solution:
•
The variance in service performance against that required by customers (should be minimal and reducing).IT SERVICE MANAGEMENT
•
The number of incidents recorded against the service (should be low and reducing).•
Increased customer and user satisfaction with the services delivered.•
Reduced customer dissatisfaction caused by poorly tested and deployed services.•
Reduced incidents and problems in deployment and production.•
Reduced discrepancies between the registered data in the CMS and the real world.ROLES
The release packaging and design manager’s responsibilities include:
•
establishing the final release configuration and building the final release;•
testing the release and publishing known errors and workarounds.The deployment manager’s responsibilities include:
•
planning, scheduling and controlling the movement of releases to test in live environments;•
ensuring that the integrity of the live environment is protected and that the correct components are released.TEST QUESTIONS FOR CHAPTER 23 ST 01, ST 14, ST 20
A 7
156