Deployment management (ITIL 4)

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

• Obtain/build
• Design and Transition
•  

Description

The purpose of the deployment management practice is to move new or changed hardware, software, documentation, processes, or any other component to live environments. It may also be involved in deploying components to other environments for testing or staging.

Deployment management works closely with release management and change control, but is a separate practice. In some organizations the term ‘provisioning’ is used to describe the deployment of infrastructure, and deployment is only used to mean software deployment, but in this case the term deployment is used to mean both.

There are a number of distinct approaches that can be used for deployment. Many organizations use a combination of these approaches, depending on their specific services and requirements as well as the release sizes, types, and impact.

• Phased deployment: The new or changed components are deployed to just part of the production environment at a time, for example to users in one office, or one country. This operation is repeated as many times as needed until the deployment is complete.
• Continuous delivery: Components are integrated, tested, and deployed when they are needed, providing frequent opportunities for customer feedback loops.
• Big bang deployment: New or changed components are deployed to all targets at the same time. This approach is sometimes needed when dependencies prevent the simultaneous use of both the old and new components. For example, there could be a database schema change that is not compatible with previous versions of some components.
• Pull deployment: New or changed software is made available in a controlled repository, and users download the software to client devices when they choose. This allows users to control the timing of updates, and can be integrated with service request management to enable users to request software only when it is needed.

Components that are available for deployment should be maintained in one or more secure locations to ensure that they are not modified before deployment. These locations are collectively referred to as a definitive media library for software and documentation, and a definitive hardware store for hardware components.

Tools that support deployment are many and varied. They are often integrated with configuration management tools, and can provide support for audit and change management. Most organizations have tools for deploying client software, and these may be integrated with a service portal to support a request management practice.

Communication around deployments is part of release management. Individual deployments are not generally of interest to users and customers until they are released.

If infrastructure is provided as a service, then deployment of new or changed servers, storage, or networking is typically managed by the organization, often treating the infrastructure as a code, so that the organization can automate deployment. In these environments it is possible that some deployments may be under the control of the supplier, such as the installation of firmware updates, or if they provide the operating system as well as the infrastructure they may deploy operating system patches. The IT organization must ensure that they know what deployments are planned, and which have happened, to maintain a controlled environment.

If application development is provided as a service, then deployment may be carried out by the external application developer, by the in-house IT department, or by a service integrator. Again, it is essential that the organization is aware of all deployments so that a controlled environment can be maintained.

In an environment with multiple suppliers it is important to understand the scope and boundaries of each organization’s deployment activities, and how these will interact. Most organizations have a process for deployment, and this is often supported with standard tools and detailed procedures to ensure that software is deployed in a consistent way. It is common to have different processes for different environments. For example, there may be one process for the deployment of client application software, and a completely different process for the deployment of server operating system patches.