Difference between revisions of "PROC23"
(Various clarifications/simplification using formal terms. Add a version and approval date.) |
|||
Line 4: | Line 4: | ||
|Doc_title = Services and Service components release and deployment process | |Doc_title = Services and Service components release and deployment process | ||
|Doc_link = https://wiki.egi.eu/wiki/PROC23 | |Doc_link = https://wiki.egi.eu/wiki/PROC23 | ||
|Version = | |Version = 2019-09-18 | ||
|Policy_acronym = OMB | |Policy_acronym = OMB | ||
|Policy_name = Operations Management Board | |Policy_name = Operations Management Board | ||
|Contact_group = operations at egi.eu | |Contact_group = operations at egi.eu | ||
|Doc_status = FINAL | |Doc_status = FINAL | ||
|Approval_date = | |Approval_date = 2018-11-29 | ||
|Procedure_statement = The procedure describes the process of release and deployment of services and service components in EGI production infrastructure | |Procedure_statement = The procedure describes the process of release and deployment of services and service components in the EGI production infrastructure | ||
|Owner = Baptiste Grenier | |Owner = Baptiste Grenier | ||
}} | }} | ||
Line 16: | Line 16: | ||
= Overview = | = Overview = | ||
The procedure describes the | The procedure describes the release and deployment of service and service components in the EGI production infrastructure. It is applicable to all production instances of the services and service components mentioned in the following list: | ||
*Accounting repository and portal | *Accounting repository and portal | ||
Line 34: | Line 34: | ||
*UMD and CMD Software provisioning infrastructure | *UMD and CMD Software provisioning infrastructure | ||
Adding and removing | Adding and removing services or services components from this list can be done by EGI central operations office, upon request, and every change is communicated to the OMB mailing list before being implemented. Please [https://ggus.eu/?mode=ticket_submit open a GGUS ticket] (ticket category: service request) to the Operations Support Unit (SU) to request any change. | ||
= Definitions = | = Definitions = | ||
Line 44: | Line 44: | ||
= Entities involved in the procedure = | = Entities involved in the procedure = | ||
*'''Service Provider team''': Team responsible for development, release and deployment of the | *'''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 | *'''Operations team''': Oversees all the process and may provide further people for testing the service or service component | ||
*'''Noc-Managers''': | *'''Noc-Managers''': Is informed regarding the release of the new service or service component and may provide further people for testing it | ||
= Requirements = | = Requirements = | ||
Line 52: | Line 52: | ||
The prerequisites are: | The prerequisites are: | ||
* | * Service or service component is part of the EGI production Infrastructure | ||
*Development team should follow [https://wiki.egi.eu/wiki/Instructions_for_Production_Tools_teams#Release_and_deployment_management | * Development team should follow [https://wiki.egi.eu/wiki/Instructions_for_Production_Tools_teams#Release_and_deployment_management Instructions for releasing] | ||
* In case of deployment of a major update of a | * In case of deployment of a major update of a service or service component, a contingency plan must be agreed with the team who operates it, to handle major disruptions caused to production activities by problems in the new version. | ||
= Acceptance criteria = | = Acceptance criteria = | ||
A new release of a | A new release of a Service or service component can be deployed in production if: | ||
* All the prerequisites are satisfied | * All the prerequisites are satisfied | ||
* The results of the testing in step ''3b'' do not show any major problem: | * The results of the testing in step ''3b'' do not show any major problem: | ||
** The | ** The Service or service component is usable with all its features | ||
** The interoperability with the other | ** The interoperability with the other Service or service component is not broken | ||
= Steps for the release of a service or service component update = | = Steps for the release of a service or service component update = | ||
Line 74: | Line 74: | ||
|- valign="top" | |- valign="top" | ||
| 1 | | 1 | ||
| Service Provider team | | Service Provider team | ||
| | | | ||
Once release is ready the team opens a GGUS ticket ('''selecting category: Release''') to Operations with the following information: | Once release is ready the team [https://ggus.eu/?mode=ticket_submit opens a GGUS ticket] ('''selecting category: Release''') to Operations SU with the following information: | ||
*Name of the | * Name of the service or service component; | ||
*Date of release; | * Date of release; | ||
*Release notes; | * Release notes; | ||
*Suggested deployment date; | * Suggested deployment date; | ||
*Testing instance url and testing instructions; | * Testing instance url and testing instructions; | ||
*Names of testers if testing is manual (if not defined Development team may ask to appoint testers); | * Names of testers if testing is manual (if not defined Development team may ask to appoint testers); | ||
*If the release is | * If the release is originating from one or multiple Change Records tracked in RT tickets as part of Change Management (CHM), then add the links to the respective RT tickets. | ||
| | | | ||
|- | |- | ||
Line 90: | Line 90: | ||
| Operations Team | | Operations Team | ||
| | | | ||
*Assess if ticket came from a change record tracked in RT: | * Assess if ticket came from a change record tracked in RT: | ||
** if yes check that the GGUS ticket contains links to the changes (RT tickets) that are implemented in this release; | ** if yes check that the GGUS ticket contains links to the changes (RT tickets) that are implemented in this release; | ||
** If not validate that the change was allowed to by-pass Change Record tracking. | ** If not validate that the change was allowed to by-pass Change Record tracking. | ||
*Inform the Noc-Managers about the upcoming release, asking if there is anyone else interested in performing the test; | * Inform the Noc-Managers about the upcoming release, asking if there is anyone else interested in performing the test; | ||
*can add further people for performing the tests; | * can add further people for performing the tests; | ||
*The suggested duration of the test phase is two weeks; | * The suggested duration of the test phase is two weeks; | ||
*Update the ticket. | * Update the ticket. | ||
| | | | ||
|- | |- | ||
Line 145: | Line 145: | ||
== Definition of emergency release == | == Definition of emergency release == | ||
An emergency release is the process of releasing one | 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; | * Major incident; | ||
* Critical security vulnerability. | * Critical security vulnerability. | ||
Line 159: | Line 159: | ||
|- valign="top" | |- valign="top" | ||
| 1 | | 1 | ||
| Service Provider team | | Service Provider team | ||
| | | | ||
Once release is ready the team opens a GGUS ticket (Selecting '''category''': '''Release''' and '''priority''': '''Top priority''') to Operations with the following information: | Once the release is ready the team [https://ggus.eu/?mode=ticket_submit opens a GGUS ticket] (Selecting '''category''': '''Release''' and '''priority''': '''Top priority''') to Operations SU with the following information: | ||
*Name of the | * Name of the Service or service component; | ||
*Date of release; | * Date of the release; | ||
*Release notes; | * Release notes; | ||
*Justification of the need for | * Justification of the need for the emergency release; | ||
*If the release is | * If the release is originating from one or multiple Change Records tracked in RT tickets as part of Change Management (CHM), then add the links to the respective RT tickets. | ||
| | | | ||
|- | |- | ||
Line 172: | Line 172: | ||
| Operations Team | | Operations Team | ||
| | | | ||
*Acknowledge the need for | * Acknowledge the need for the emergency release; | ||
*Update the ticket. | * Update the ticket. | ||
| | | | ||
|- | |- | ||
Line 183: | Line 183: | ||
| 4 | | 4 | ||
| Service Provider team | | Service Provider team | ||
| Deploy release and update the ticket. | | Deploy the release and update the ticket. | ||
| | | | ||
|- | |- | ||
Line 235: | Line 235: | ||
| Baptiste Grenier | | Baptiste Grenier | ||
| 2018-11-29 | | 2018-11-29 | ||
| Introduce specific steps for emergency releases. Slightly | | Introduce specific steps for emergency releases. Slightly re-organise steps for standard releases. | ||
|- | |||
| | |||
| Baptiste Grenier | |||
| 2019-09-18 | |||
| Various clarifications/simplification using formal terms. | |||
|} | |} | ||
[[Category:Operations_Procedures]] | [[Category:Operations_Procedures]] |
Revision as of 12:32, 18 September 2019
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 describes the process of release and deployment of services and service components in the EGI production infrastructure |
Owner | Baptiste Grenier |
Overview
The procedure describes the release and deployment of service and service components in the EGI production infrastructure. It is applicable to all production instances of the services and service components mentioned in the following list:
- Accounting repository and portal
- AppDB
- ARGO Messaging Services
- ARGO/SAM
- CheckIn (AAI Support)
- Collaboration tools
- DIRAC4EGI
- EGI Catch-all services
- EGI Marketplace
- GGUS
- GOCDB
- Operations portal and VAPOR
- PERUN
- Security monitoring
- UMD and CMD Software provisioning infrastructure
Adding and removing services or services components from this list can be done by EGI central operations office, upon request, and every change is communicated to the OMB mailing list before being implemented. Please open a GGUS ticket (ticket category: service request) to the Operations Support Unit (SU) to request any change.
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:
- Service or service component is part of the EGI production Infrastructure
- Development team should follow Instructions for releasing
- In case of deployment of a major update of a service or service component, a contingency plan must be agreed with the team who operates it, to handle major disruptions caused to production activities by problems in the new version.
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. |