Difference between revisions of "PROC23"
(Drop service list and clarify it's scoped to all centrally provided IT services part of the EGI catalogue) |
m (→Requirements) |
||
Line 35: | Line 35: | ||
* Centrally-provided Service or service component part of the EGI production Infrastructure; | * Centrally-provided Service or service component part of the EGI production Infrastructure; | ||
* Development team should | * Development team should refer to the [[EGI_Change_Management|EGI Change management]] documentation. | ||
= Acceptance criteria = | = Acceptance criteria = |
Revision as of 11:56, 22 January 2020
Main | EGI.eu operations services | Support | Documentation | Tools | Activities | Performance | Technology | Catch-all Services | Resource Allocation | Security |
Documentation menu: | Home • | Manuals • | Procedures • | Training • | Other • | Contact ► | For: | VO managers • | Administrators |
Title | Services and Service components release and deployment process |
Document link | https://wiki.egi.eu/wiki/PROC23 |
Last modified | 2019-09-18 |
Policy Group Acronym | OMB |
Policy Group Name | Operations Management Board |
Contact Group | operations at egi.eu |
Document Status | FINAL |
Approved Date | 2018-11-29 |
Procedure Statement | The procedure provides steps for service updates and releases of the centrally-provided production services. |
Owner | Baptiste Grenier |
Overview
The procedure describes the release and deployment of the centrally-provided IT service and service components part of the EGI Service Catalogue.
Definitions
Please refer to the EGI Glossary for the definitions of the terms used in this procedure.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", “MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Entities involved in the procedure
- Service Provider team: Team responsible for development, release and deployment of the service or service component
- Operations team: Oversees all the process and may provide further people for testing the service or service component
- Noc-Managers: Is informed regarding the release of the new service or service component and may provide further people for testing it
Requirements
The prerequisites are:
- Centrally-provided Service or service component part of the EGI production Infrastructure;
- Development team should refer to the EGI Change management documentation.
Acceptance criteria
A new release of a Service or service component can be deployed in production if:
- All the prerequisites are satisfied
- The results of the testing in step 3b do not show any major problem:
- The Service or service component is usable with all its features
- The interoperability with the other Service or service component is not broken
Steps for the release of a service or service component update
Responsible | Action | Notes | |
---|---|---|---|
1 | Service Provider team |
Once release is ready the team opens a GGUS ticket (selecting category: Release) to Operations SU with the following information:
|
|
2 | Operations Team |
|
|
3a | Operations Team / Noc-Managers | Update the ticket with the information on the performed tests and their result. | |
3b | Service Provider team | Update the ticket with information about results of the overall testing phase. | |
4 | Service Provider team | Provide in the ticket the link to updated documentation. | |
5 | Service Provider team and Operations team | Agree on an appropriate deployment date and update the ticket. | |
6 | Operations team | 10 days before the upcoming deployment, inform the Noc-Managers.
Update the ticket. |
|
7 | Service Provider team | Schedule a downtime of the service in case it is needed. | |
8 | Service Provider team | Deploy release and update the ticket. | |
9 | Operations team | Close the GGUS ticket after a week of the deployment only if the release was successful. |
Emergency release
Definition of emergency release
An emergency release is the process of releasing one Service or service component, or a set of Services or service components, with the targeted goal of solving a specific problem affecting the EGI infrastructure. To qualify the problem for an emergency release the problem should be classified in at least one of the following categories:
- Major incident;
- Critical security vulnerability.
Steps for emergency release
Responsible | Action | Notes | |
---|---|---|---|
1 | Service Provider team |
Once the release is ready the team opens a GGUS ticket (Selecting category: Release and priority: Top priority) to Operations SU with the following information:
|
|
2 | Operations Team |
|
|
3 | Service Provider team | Record an unplanned downtime of the service in case it is needed. | |
4 | Service Provider team | Deploy the release and update the ticket. | |
5 | Operations team | Inform the Noc-Managers about the update.
Update the ticket. |
|
6 | Operations team | Close the GGUS ticket after a week of the deployment only if the release was successful. |
Revision History
Version | Authors | Date | Comments |
---|---|---|---|
Alessandro Paolini | 2016-03-22 | procedure revised and made some changes | |
Alessandro Paolini | 2016-07-25 | added the new AAI in the tools list | |
Baptiste Grenier | 2018-10-01 | Introduced usage of new ticket category "release" | |
Alessandro Paolini | 2018-10-11 | Updated the list of services under scope; some typos corrections. | |
Baptiste Grenier | 2018-11-20 | Existing CHM ticket should be mentioned when applicable; rephrase to use services and services components terms instead of tools. | |
Baptiste Grenier | 2018-11-29 | Introduce specific steps for emergency releases. Slightly re-organise steps for standard releases. | |
Baptiste Grenier | 2019-09-18 | Various clarifications/simplification using formal terms. Update procedure statement. Drop old instructions for providers that have been replaced by CHM documentation. |