Release unit and release package A ‘release unit’ describes the portion of a service

or IT infrastructure that is normally released as a single entity according to the organization’s release policy. The unit may vary, depending on the type(s) or item(s) of service asset or service component such as software and hardware. Figure 4.17 gives a simplified example showing an IT service made up of systems and service assets, which are in turn made up of service components.

The actual components to be released on a specific occasion may include one or more release units, or exceptionally may include only part of a release unit. These components are grouped together into a release package for that specific release.

In Figure 4.17 the assets and components might be:

■ A1 Server

■ A2 Application

■ A2.1 Main application, developed within the IT organization

■ A2.1.1 Commercial off-the-shelf reporting software used by the application

■ A2.2 Second application, developed within the IT organization

■ A3 Client software, developed within the IT organization

■ A3.1 Commercial off-the-shelf library providing supporting routines for the client application.

The general aim is to decide the most appropriate release-unit level for each service asset or

component. An organization may, for example, decide that the release unit for business-critical applications is the complete application in order to ensure that testing is comprehensive. The same organization may decide that a more appropriate release unit for a website is at the page level.

A ‘release package’ is a set of configuration items that will be built, tested and deployed together as a single release. Each release will take the documented release units into account when designing the contents of the release package. It may sometimes be necessary to create a release package that contains only part of one or more release units, but this would only happen in exceptional circumstances.

The following factors should be taken into account when deciding the appropriate level for release units:

■ The ease and amount of change necessary to release a release unit

■ The amount of resources and time needed to build, test, distribute and implement a release unit

■ The complexity of interfaces between the proposed unit and the rest of the services and IT infrastructure

■ The storage available in the build, test, distribution and live environments.

Releases should be uniquely identified according to a scheme defined in the release policy as discussed in section 4.1.4.2. The release identification should include a reference to the CIs that it represents and

IT service A

A1 A2 A3

A2.1 A2.2 A3.1

A2.1.1

Figure 4.17 Simplified example of release units for an IT service

Service transition processes ^|

117

a version number that will often have two or three parts, e.g. emergency fix releases: Payroll_System v.1.1.1, v.1.1.2, v.1.1.3.

Designing releases and release packages Figure 4.18 provides an example of how the architectural elements of a service may be changed from the current baseline to the new baseline with releases at each level. The architecture will be different in some organizations but is provided in this section to give a context for release activities.

The release teams need to understand the relevant architecture in order to be able to plan, package, build and test a release to support the new or changed service. This helps to prioritize the release activities and manage dependencies: e.g. the technology infrastructure needs to be ready – with service operation functions prepared to support it with new or changed procedures – before an application is installed.

Figure 4.18 also shows how the service architectural elements depend on the service portfolio that defines the service offerings and service packages.

Dependent services will need to be built and tested in service transition. For example, an IT financial service may be dependent on several internal support services and an external service. For more details about the structure of services, see ITIL Service Strategy and ITIL Service Design.

There are normally dependencies between

particular versions of service components required for the service to operate. For example, a new

version of an application may need an upgrade to the operating system and one or other of these could require a hardware change, e.g. a faster processor or more memory. In some cases, the release package may include documentation and procedures. These could be deployed via a manual update or through an automatic publishing mechanism, e.g. to the SKMS/website.

A release package may be a single release unit or a structured set of release units such as the one shown in Figure 4.19. A release package may contain only part of one or more release units. This would only happen in exceptional circumstances, for example when creating an emergency release.

The example in Figure 4.19 shows an application with its user documentation and a release unit for each technology platform. On the right there is the customer service asset that is supported by two supporting services – SSA for the infrastructure service and SSB for the application service. These release units will contain information about the service, its utilities and warranties and release documentation. Often there will be different ways of designing a release package, and

consideration should be given to establishing the most appropriate method for the identifiable circumstances, stakeholders and possibilities.

Where possible, release packages should be designed so that some release units can be removed if they cause issues in testing.

Business/organization

Current baseline (as is)

Business/organization

Target baseline (to be)

SA RO1

Figure 4.18 Architecture elements to be built and tested

118

valuable release windows

A UK government department is especially well placed to make full use of all available release windows. The staff work in a secure financial, low-risk environment, with carefully planned changes scheduled well in advance and allocated to pre-arranged release windows, which are scheduled several months apart. Because of their careful and longer-term planning, when a change proves unsuitable for release (i.e. tests are failed), alternative, quality-assured changes are usually available – prepared and tested but lower in business priority and so targeted at later releases. These can be accelerated to make use of the unexpected vacancy created by the test failure. The test and build process also allows elements of later scheduled releases to be slotted in for release, or successful components of the failed release to be implemented, even though the full product is not ready. This allows the subsequent fuller release to be a ‘smaller’

product, which means that further additional changes can be scheduled alongside it in later release windows.

Any significant new or changed service or service offering will require the deployment stage to consider the full range of elements comprising that service – infrastructure, hardware, software, applications, documentation, knowledge etc.

Effectively, this means that the deployment will contain sub-deployments for elements comprising the service as illustrated in Figure 4.20. The combination, relationship and interdependencies of these components will require careful and considered planning. Significant deployments will be complex projects in their own right.

To understand the deployment options, a high-level assessment of the deployment units, locations and environments may be required, for example:

■ Assessment baseline – this is a snapshot of the relevant environment, services and infrastructure, including ‘softer’ elements such as skills level and attitudes where applicable, and should be taken as a first step.

■ Identify the components – this may include deciding on the best way to break down a major deployment into components. Often there will be different ways of achieving this

User

documentation Application release unit

Web client Database

change Central server software Release package A9

V1.0

Customer service A

Release

documentation SSA SSB

SSAU1

SSAU2

SSAU3

SSAU4

Figure 4.19 Example of a release package

Service transition processes ^|

119

breakdown, and consideration needs to be given to establishing the most appropriate method for all the identifiable circumstances, stakeholders and possibilities.

■ Determine the appropriate deployment approach for each.

4.4.4.3 Deployment options and