Document control

AreaEGI Release and Deployment Management RDM
Policy status

FINALISED

Owner

Catalin Condurache

Approval status

APPROVED

Approved version and date

v8  

StatementThe goal of Release Management is to plan and oversee the implementation of approved Changes into production.
Dissemination Level

TLP:WHITE - Public

Goal

The goal of Release Management is to plan and oversee the implementation of approved Changes into production.

Scope

Release Management applies exclusively to all EGI branded services in the service catalogue of EGI Foundation.

Release Management operates as a peer process in conjunction with Change Management and as such augments and supports the existing change management policy and processes. It covers all Changes that are approved by Change Management.

UMD

Middleware releases (UMD) are managed by the Validated Software and Repository service and not fall under the responsibility of the RDM process and are subject to the procedure PROC25 defined in the EGI Wiki.

Policy

Bundled changes

Typically Releases are linked to a single change as we expect providers to be bundling changes.

Planning of releases

Due to the federated nature of EGI Activities RDM is currently mainly working in a reactive way, having providers propose their changes once they are ready. Then releases deployment dates are still agreed with the RDM staff.

All changes to IT resources, services and / or systems approved by Change Management are required to follow this Release policy. 

All releases will follow the change process as defined by the CHM1 Manage changes including emergency changes procedure.

Each regular release requires the following:

Release Plan: It includes date of release, release notes, recommended duration of testing period, expected deployment in production date, access to documentation for users and administrators (if applicable), location of the packages (if applicable), the deployment procedure (if applicable).

Contingency Plan:  It includes the means to deal with disruptions caused by an unsuccessful change of high impact or high risk. This can be avoided in the case of an emergency release. 

Testing:  All regular releases must be tested in a controlled acceptance test environment prior to implementing. If a controlled test environment is not available, best effort is acceptable until such controlled test environment becomes available.

Release frequency: The maximum releases frequency is once per month (per service). Emergency releases are not computed in the frequency.

For lightweight releases: A simplified release plan will apply to changes classified with low risk and low impact by CHM.

For emergency releases: The emergency change process as defined by the CHM1 Manage changes including emergency changes procedure will be followed for all emergency changes.

Table of Contents