Document code: PRO-00XX.

01
Security level: Internal

Effective date: 31/12/2016

Release and Deployment Management

1. Purpose
This document describes the release and deployment management process at ECHA.

2. Scope
A release in this context refers to an approved set of changes that can require changes to
existing or creation of new virtual assets, software, training, manuals, guidance documents
and services. The scope of this document is to address how to plan, build, test and deploy
a release.
The process starts by receiving an authorised change from change management process
(see PRO-0024) or project management process (see PRO-0026 and PRO-0027) to plan,
build, test and deploy a production-ready release package. The process ends after the
release is supported in production, old services have been retired and assets
decommissioned.
The process is dependent on the change management process or project management
process for the approval at specific steps:
 Authorise the planning of a release
 Authorise the build and test of a release
 Authorise the deployment of a release to production
 Authorise the closure of the release and deployment management process
During the course of release and deployment management at least the following steps will
take place:
 Identifying the affected services and configuration items and analysing the impact
on them
 Defining when the process is finalised, who are the authorising parties for finalisation
and what are the success criteria
 Scheduling release and deployment plans with business units
 Creating release packages for test and production
 Deploying the release packages
 Transferring knowledge to service operation and end users
 Keeping log of deviations and risks and managing them
 Retiring services and decommissioning assets
Linkage to ECHA Process System

L1. Activity: 15. Information and Communication Technology

L2. Process: 15.01 ICT Governance

L3. Sub-process: N/A

3. Description

TEM-0001.03
Uncontrolled copy once printed. Ensure that the right version is in use. Page 1 of 14
 Document code: PRO-00XX.01
Security level: Internal

Effective date: 31/12/2015

Release and Deployment Management

ECHA’s release and deployment management is based on good practices (ITIL v3). The
process begins with a receipt of an authorised change from change management process or
project management process for an initial release scope. In the first phase of the process
the scope is analysed for feasibility, cost and impact to arrive to the final scope to be built.
Releases are driven from business (PdM) and service needs (SM) and possibly restricted by
implementation resources (development, ADSM, testing, operations) and budget. The final
scope as well as the steps to deploy it into production have to be authorised by the initiating
process.
The authorising entity will also nominate a Release Manager (RM) that will be in charge of
the release. The required skill level as well as availability should be taken into account when
nominating the RM. The default nomination is the SM of the service that is mostly affected
by the release.

3.1. Release definition

A release is a set of changes approved by the project or change management process and
typically divided into several release units forming a single release package. A release unit
can be:
 Physical assets such as servers and network equipment
 Virtual assets such as virtual servers and appliances
 Applications and software
 Training for end users and IT staff
 Manuals and guidance documentation for end users
 Services
The figure 1 below describes the suggested approach for release units.

Release package

Application and Training and

Infrastructure Services release
software release manuals release
release unit unit
unit unit

Physical and virtual Middleware Application delivery

Code/application
server installation installation and tool chain Release notes End-user training Manuals Service changes
deliverable
and configuration configuration configuration

Figure 1: Release package

Whenever possible, the release units should be independent so that a release can take place
even if some of the release units were dropped out or postponed during the process. Not all
release packages have each of the proposed release units.

3.1.1. Infrastructure release unit

An infrastructure release unit contains at least one of the following:

 Setup and / or configuration of a physical or virtual server or virtual appliance with
the proposed capacity (memory and virtual CPUs) and with the target operating
system

TEM-0001.03
Uncontrolled copy once printed. Ensure that the right version is in use. Page 2 of 14
 Document code: PRO-00XX.01
Security level: Internal

Effective date: 31/12/2015

Release and Deployment Management

 Setup and / or configuration of a middleware component (web server, application

server, database etc.)
 Configuration of the application delivery tool chain
If there are multiple services or products in the release scope, it is suggested to create a
separate infrastructure release unit for each.

3.1.2. Application and software release unit

An application and software release unit contains one of the following (including the release
notes):
 Hotfix: a hotfix typically fixes a single emergency issue, and is released as fast as
possible after all necessary phases have been completed (for example, sufficient
testing to prevent further problems and after industry communication has happened
in case of visible downtime)
 Patch: patches typically fix a number of issues. Patches accumulate small changes
over a period of time and are deployed periodically according to a predefined
schedule.
 Minor or major release: minor or major releases typically introduce minor and /
or major new functionality, functional improvements and fix existing issues.
If there are multiple products in the release scope, it is suggested to create a separate
application and software release unit for each. Hotfixes or patches that do not require any
other release units (changes to infrastructure etc.), can be handled as part of the change
management process.

3.1.3. Training and manuals release unit

The training and manuals release unit contains at least one of the following:
 Training and manuals for end-users on how to use the application or service
 Training and manuals for support organisation on how to support the application or
service
If there are multiple services or products in the release scope, it is suggested to create a
separate training and manuals release unit for each.

3.1.4. Services release unit

The services release unit contains at least one of the following:

 Changes and updates to the service portfolio
 Changes and updates to the service cards and technical descriptions
 Changes and updates to PROs
 Configuration of the helpdesk tools
If there are multiple services in the release scope, it is suggested to create a separate
services release unit for each.

3.2. Rolling application release unit plan

In order to facilitate planning, the PM or SM controls and maintains a detailed 18 month

rolling release plan for application release units approved by the corresponding CAB or PB,

TEM-0001.03
Uncontrolled copy once printed. Ensure that the right version is in use. Page 3 of 14
 Document code: PRO-00XX.01
Security level: Internal

Effective date: 31/12/2015

Release and Deployment Management

showing always the releases that have been planned and / or committed for the next 18
months. The preliminary dates are communicated in the project release calendar for projects
and service release calendar for maintenance releases. The approved release dates are
added to the change management calendar. All of the above can be seen in a single
dashboard (see ref 1).
In addition, the CAB or PB maintains a long-term release road map for the foreseen release
needs beyond 18 months. The release needs in the road map will be clarified, planned and
/ or committed once they move to the 18 month rolling release plan. The release needs
submitted to CAB or PB for the long-term release road map will have an advantage over
conflicting release requirements of similar priority that were submitted later.
The target number of releases can vary from continuous delivery (several small incremental
releases with short testing periods) to a single major release per year (with an extended
testing period). The basic guideline is that the releases should take place in a predictable
manner and at a frequency conciliating the need of the business and the resource
constraints and efficiency of the process (e.g. quarterly).

3.3. Phases

Release and deployment management process is divided into four phases:

 release and deployment planning
 release build and test
 deployment
 review and close
At the end of each phase authorisation to move to the next phase is requested from the
entity that authorised the release.

3.3.1. Release and deployment planning

This phase starts with the receipt of an authorised change to plan a release. The target
scope of the release can be partially open at this stage and only after cost, impact and effort
estimation the final scope is agreed. The target for the first phase can be e.g. to clearly
investigate the impact of the release, to define the scope based on available budget, to
define the scope based on available resources or to define the scope based on time boxed
deliveries. In case of a partially open scope the changes should be adequately prioritised in
the initial plan to form the final scope.
The planning phase should take into account all the criteria for the successful completion of
the release. The main purpose is to provide a solid plan for the subsequent phases by
identifying all necessary actors, required resources, costs and affected services. Identifying
the pass/fail criteria for the final deployment should already be defined at this stage.
The first step is to analyse the impact of the release. The following four angles should be
taken into account:
 Identifying the affected business services, stakeholders and end users
 Identifying the affected technical services
 Identifying the changes to application architectures
 Identifying the changes to technology architecture
The RM will identify the PMs, SMs and PdMs that need to be involved in the planning to
evaluate the impact on services, stakeholders and end users. ADSMs will be involved for

TEM-0001.03
Uncontrolled copy once printed. Ensure that the right version is in use. Page 4 of 14
 Document code: PRO-00XX.01
Security level: Internal

Effective date: 31/12/2015

Release and Deployment Management

impact on the application architectures and the technology architecture and will consult the
CTO when required. Capacity needs will be communicated to the capacity management
process by the ADSM. If there is any technical impact on business continuity, resilience or
availability levels, the ADSM shall trigger the IT-BCP Advisory Service. In case the business
continuity requirements have changed the product manager shall trigger the IT-BCP
Advisory Service.
Once the impact has been identified the release package will be defined containing the
required release units.
The direct costs should be estimated by the RM by e.g. quoting the FTE-days required from
external contractors, or direct fees resulting from resource requirements (capacity, licenses,
etc.) for any of the phases. For release units involving external parties this planning is
typically done together with the external party. ADSMs will provide the cost estimation
regarding hosting services.
The plan for build and test phase should contain:
 The testing cycle of each release unit and dependencies between release units
 The environments that will be required to validate the release units
 Necessary configurations for support tools and application delivery tool chain
 The resources needed for providing the environments and necessary technical
preparations for receiving the release, especially when infrastructure release units
are included
 Capacity requirements for build and test phase
 The resources needed for service validation or quality assurance of the release
package
 The timeline for each of the actions taking into account lead times and logistics
The plan for deployment should contain:
 The release cycle of each release unit and dependencies between release units taking
into account ECHA internal deadlines, external commitments and legal deadlines
 Communication plan, documentation and training for end-users and IT staff
 Technical deployment actions
 Necessary configurations for support tools and application delivery tool chain
 Capacity requirements for production
 Rollback plan
The plan for review and close should contain:
 Organisation of the early support phase
 Criteria for closing the release process
 Retiring services and decommissioning assets
Finally RM will establish a risk list for the release and will maintain it throughout the phases.
Optionally an existing risk list from the project can be updated and maintained.
Once the planning is completed the release and deployment plan is submitted to the project
or change management process for approval before moving on to the next phase. In case
the target of the first phase was also to finalise the scope this phase may be an iterative
approach before the final scope and the related planning has been finalised. The plan is
recorded as part of the PB or CAB meeting minutes.

3.3.2. Release build and test

TEM-0001.03
Uncontrolled copy once printed. Ensure that the right version is in use. Page 5 of 14
 Document code: PRO-00XX.01
Security level: Internal

Effective date: 31/12/2015

Release and Deployment Management

After receiving authorisation for build and test, this phase begins according to the plan from
the previous phase.
The request for capacity needs to be an early step to prepare the testing and production
environments in due time. When working with third parties, the contractor is typically
providing the logical system architecture which can be used to build a plan for the required
environments. In case of changes to application architecture or technology architecture, a
system architecture review by the CTO is required before completing the build of
environments. The ADSM will handle the capacity requests and CTO interaction.
In case of external software vendors a software delivery to ECHA will also take place in this
phase. The software delivery also contains the deployment guides prepared according to
ECHA guidelines (see ref 2) that will enable the installation and setup of the infrastructure
and application and software release units. For external software deliveries the SM or PM
will act as the contract manager handling the development project.
In case of an external hosting party, the ADSM will coordinate the necessary work with
them.
All new environments, including production environments, will be built in this phase. Also
the necessary configurations for the support tools and application delivery tool chain (see
ref 3) are performed.
Once a release unit is available, it needs to go through service validation or quality
assurance as specified in HAN-0014. Testing for each release unit is organised by either the
PM or SM and handled by the Quality and Testing Manager (TM). Testing policy for each
release unit defines the pass/fail criteria to conclude the testing. The service validation or
quality assurance should also take into account the deployment readiness and quality of the
release notes as well as integration testing. The PdM is actively involved and the SM has the
final approval that the service is ready for production use.
In some cases a service rehearsal with stakeholders might be required before the
deployment phase to verify the plans and catch any unexpected behaviour.
The project or change management process should be informed in case there are any
deviations from the initial plan for this phase and the risk list should be kept continually up-
to-date. If the release package has been successfully tested, the final step will be to request
authorisation for deployment from the project or the change management process.

3.3.3. Deployment

The deployment phase is the transition of the release package to production. While the
authorisation for the deployment has been received at this stage, the first step is to find a
suitable slot for the go-live. The go-live scheduling is handled by the infra CAB and requested
with an RFC (see ref 4). The infra CAB will make the decision on the go-live date balancing
the requirements for all simultaneously requested deployment activities. The infra CAB will
target to grant the requested go-live date whenever feasible.
Depending on the release the deployment can be a staged approach where release units
are deployed at different times or a big bang approach where all the release units are
released together. Pilot users can also be considered so that the release package or release
unit is only made available to a small set of representative end-users before the final
deployment to all end-users.
Before deployment is started the final checks will be made:

TEM-0001.03
Uncontrolled copy once printed. Ensure that the right version is in use. Page 6 of 14
 Document code: PRO-00XX.01
Security level: Internal

Effective date: 31/12/2015

Release and Deployment Management

• Reviewing the risk list from previous phases and possible additions due to unforeseen
circumstances, late changes etc.
• Assessing that the necessary capacity and licenses have been requested and exist
• Reviewing that the service portfolio, ticketing system, business continuity plans and
knowledge transfer activities are ready for the deployment
• Reviewing the communication plan and ensuring the stakeholders and end-users are
informed of the upcoming change
• Reviewing the rollback plan
• Ensuring that the release package is stored in a definite media library or versioning
system
Once everything is ready the deployment can start according to the agreed timeframe. In
the deployment phase following the deployment plan:
 The necessary materials and processes are deployed and released (applications,
documentation, ticketing system changes, communication etc.)
 The success of the deployment is tested and verified according to acceptance criteria
 Immediate feedback is gathered from main stakeholders
Some release units can be made available in a pull mode (e.g. desktop software installation)
so that it is available to the end users, but they will decide when to actuate the change. For
others the release will always be in push mode (e.g. new version of a web application) where
the users cannot decide when the change will be effective.
After the deployment the infra CAB is informed of the outcome as well as the initial
authorising body. For successful releases the final phase will now start with early life support
of the release.
In case of issues the authorising body and the infra CAB are informed and the authorising
body will decide whether to postpone or abandon the release. If authorisation for postponing
the release is received, the reasons for failure are analysed, plans modified and another go-
live date is requested from the infra CAB.

3.3.4. Review and close

This is the final phase before transitioning to normal service. Depending on the scope of the
release this stage can vary from a few hours to a few weeks.
All the necessary documentation needs be finalised, transition activities need be closed, the
known errors and workarounds need to be documented and accepted, old services need to
be retired and assets decommissioned. Before closing the phase also feedback and lessons
learned are collected and fed to the continual improvement process.
During early life support the affected systems are monitored more closely for incidents and
unexpected behaviour by the SM liaising closely with the PdM and ADSM. Also more helpdesk
tickets can be expected and should be addressed accordingly. Based on pre-defined criteria
the closure can only be requested when the criteria is met (e.g. number of tickets has
decreased to normal).
Concurrent to the early life support is the service retirement of old services and
decommissioning of servers, application environments, applications, licenses etc. that are
no longer needed.
Once the early support criteria are met and the service retirement and assets
decommissioning are completed, the closure of the review and close phase is requested

TEM-0001.03
Uncontrolled copy once printed. Ensure that the right version is in use. Page 7 of 14
 Document code: PRO-00XX.01
Security level: Internal

Effective date: 31/12/2015

Release and Deployment Management

from the project or change management process. Once the request is accepted the release
management process will end.

3.4. RACI matrix

The responsibilities in each phase are detailed as a RACI-matrix.

R = Responsible (responsible for executing the task)
A = Approval (give approval before task is executed)
C = Consult (two-way flow of information – iterative feedback)
I = Inform (one-way flow of information – no need for feedback)
SM should be interpreted as the business service manager and ADSM as ADSM or technical
service manager.

Task PM SM PdM TM RM ADSM

Phase I

Affected end-user services C C C I R I

Affected technical services I I R

Changes to application C I R
architecture

Changes to technology I I R
architecture

Impact on capacity I R

Business impact on BCP C C R C C

Technical impact on BCP C C C C R

Infrastructure release unit I R

definition

Application and software I R

release unit definition

Training and manuals I I R I

release unit definition

Services release unit R R I I

definition

Cost estimation C C R C

TEM-0001.03
Uncontrolled copy once printed. Ensure that the right version is in use. Page 8 of 14
 Document code: PRO-00XX.01
Security level: Internal

Effective date: 31/12/2015

Release and Deployment Management

Task PM SM PdM TM RM ADSM

Plan phase II C C C C R C

Plan phase III C C C R C

Plan phase IV C C C R C

Establish risk list C C C C R C

Phase II

Initiate system architecture I R

review

Request planned capacity I R

Align software deliveries R R I C

with ECHA guidelines

Development contract R R I
management

Hosting services contract I I R

management

Support tools configuration C R C

Application delivery tool I R

chain configuration

Prepare environments I I R

Service validation I A C R I I

Review risk list R

Phase III

Prepare RFC C C R

Review risk list R

Execute communication I R C I
plan

Support tools configuration C R C

TEM-0001.03
Uncontrolled copy once printed. Ensure that the right version is in use. Page 9 of 14
 Document code: PRO-00XX.01
Security level: Internal

Effective date: 31/12/2015

Release and Deployment Management

Task PM SM PdM TM RM ADSM

Infrastructure release unit I R

deployment

Application and software I R

release unit deployment

Training and manuals I R I

release unit deployment

Services release unit R I I

deployment

Service validation R C I C

Rollback C C R C

Phase IV

Early life support R C I C

Retire services and C C R C

decommission assets

Assess the closure criteria C I R C

Lessons learned C C C C R C

TEM-0001.03
Uncontrolled copy once printed. Ensure that the right version is in use. Page 10 of 14
 Document code: PRO-00XX.01
Security level: Internal

Effective date: 31/12/2015

Release and Deployment Management

4. Flowchart
Project / Programme Management
Ready for build Ready for RFC Ready for
Start
and test? deployment? normal service?

No
Project
Work
No No

Yes Yes

Receive an
authorised request Release and Retire services
Early life
to plan, build, test deployment Build and test and
support
and deploy a planning decommission
release
Release manager Release manager Release manager Release manager
Release manager Project Manager Release manager Service manager Service manager
Testing coordinator ADSM ADSM ADSM
ADSM
Release and Deployment Deployment End

Management
Release manager
Service Manager Yes Release manager Release manager
Release manager Testing coordinator Service manager Service manager
Release manager ADSM ADSM ADSM
Receive an
authorised request Release and Retire services
Early life
to plan, build, test deployment Build and test and
support
and deploy a planning decommission
release

Yes
Yes

No No
Maintenance
Work
No
Ready for build Ready for Ready for
Start Yes
and test? deployment? normal service?

Change Management

Yes

Scheduling go-
Successful?
live
RFC
Change Management
(infra CAB) No

Figure 2: Release and deployment management process

5. Definitions

Term or abbreviation Definition

ADSM Application Delivery Service Manager

CAB Change Advisory Board is a body that pre-approves standard

changes and approves normal changes

CTO Chief Technology Officer

ITIL Information Technology Infrastructure Library

PB Project Board

PdM Product Manager

TEM-0001.03
Uncontrolled copy once printed. Ensure that the right version is in use. Page 11 of 14
 Document code: PRO-00XX.01
Security level: Internal

Effective date: 31/12/2015

Release and Deployment Management

Term or abbreviation Definition

PM Project Manager

RFC Request For Change

RM Release Manager

SM Service Manager

TM Quality and Testing Manager

6. References

Associated document code Document name

Ref 1 Calendar dashboard

Ref 2 ECHA technical guidelines for contractors

Ref 3 Application delivery service model

Ref 4 Request for change

IQMS document code Document name

HAN-0014 ICT Software Testing Handbook

PLA-0015 IT BCP - IT continuity Technical Preparedness Plan

PRO-0024 ICT Change Management

PRO-0026 ICT Governance bodies, roles and description

PRO-0027 ICT Governance and Process Description

PRO-0030 ICT Communication

PRO-0031 ICT Service Definition

PRO-0058 IT Product Management

7. Records

No Record name

1 RFC (Request For Change)

TEM-0001.03
Uncontrolled copy once printed. Ensure that the right version is in use. Page 12 of 14
 Document code: PRO-00XX.01
Security level: Internal

Effective date: 31/12/2015

Release and Deployment Management

No Record name

2 CAB or PB meeting minutes

No Record owner Storage location Security level Comments

Service, Project or
1 CAB or PB Product filing plan as Internal
appropriate

Service, Project or
2 CAB or PB Product filing plan as Internal
appropriate

8. Annexes
n/a

TEM-0001.03
Uncontrolled copy once printed. Ensure that the right version is in use. Page 13 of 14
 Document code: PRO-00XX.01
Security level: Internal

Effective date: 31/12/2015

Release and Deployment Management

9. Change history

Revision Changed section Change description Date

1 - Initial document 26/02/2015

2 All Updated after first discussion 18/03/2015

3 All Updated after service forum discussion 10/04/2015

4 All Updated to address comments 14/04/2015

5 RACI matrix Updated with outsourced application services 26/05/2015

6 All Aligned the text with the RACI changes 28/05/2015

7 All Updated after discussion with SharePoint and 10/06/2015

Dissemination

8 RACI matrix Modified RACI 11/06/2015

9 RFC Added link to infra CAB RFC 12/06/2015

10 RACI matrix Added release package definitions in the RACI 26/06/2015

11 All Responded to comments 25/09/2015

TEM-0001.03
Uncontrolled copy once printed. Ensure that the right version is in use. Page 14 of 14