Designing release 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 release s at each level. The architecture will be different in some organizations but is provided in this section to give a context for release and deployment activities. The release and deployment 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 and deployment activities and manage dependencies, e.g. the technology infrastructure needs to be ready with operations staff ready to support it with new or changed procedure s before an application is installed.

Figure 4.18 Architecture elements to be built and tested

Figure 4.18 also shows how the service architectural elements depend on the Service Portfolio that defines the service offerings and service package s. 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 the Service Strategy and Service Design publications.

There are normally dependencies between particular version s of service component s required for the service to operate. For example a new version of an application may require an upgrade to the operating system and one or other of these two changes could require a hardware change, e.g. a faster processor or more memory. In some cases, the release package may consist of a set of 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.

Figure 4.19 Example of a release package

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 service s – 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 needs to be given to establishing the most appropriate method for the identifiable circumstances, stakeholder s and possibilities.

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

Дата добавления: 2015-10-29