Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "PROC23"

From EGIWiki
Jump to navigation Jump to search
(Drop redundant step, RT ticket are checked at the beginning)
m (Typo and style)
Line 67: Line 67:
{| width="906" height="305" class="wikitable"
{| width="906" height="305" class="wikitable"
|-
|-
! <br>
!
! Responsible  
! Responsible  
! Action  
! Action  
! Notes
! Notes
|- valign="top"
|- valign="top"
| 1<br>
| 1
| Service Provider team<br>
| Service Provider team<br>
|  
|  
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 opens a GGUS ticket ('''selecting category: Release''') to Operations with the following information:


*Name of the tool
*Name of the tool;
*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 changes is one orginating from a Change Record tracked in an RT ticket as part of CHM, then add the link to the respective RT ticket for that change
*If the release is one originating from one or multiple Change Records tracked in RT tickets as part of CHM, then add the links to the respective RT tickets.
|
|
|-
|-
Line 89: Line 89:
| 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 tests
*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.
|
|
|-
|-
| 3a
| 3a
| Operations Team / Noc-Managers
| Operations Team / Noc-Managers
| Update the ticket with the information on the performed tests and their result
| Update the ticket with the information on the performed tests and their result.
|
|
|-
|-
| 3b
| 3b
| Service Provider team
| Service Provider team
| Update the ticket with information about results of the overall testing phase<br>
| Update the ticket with information about results of the overall testing phase.
| <br>
|
|-
|-
| 4<br>
| 4
| Service Provider team
| Service Provider team
| Provide in the ticket the link to updated documentation<br>
| Provide in the ticket the link to updated documentation.
| <br>
|
|-
|-
| 5
| 5
| Service Provider team and Operations team<br>
| Service Provider team and Operations team
| Agree on deployment date and update the ticket
| Agree on deployment date and update the ticket.
| <br>
|
|-
|-
| 6
| 6
| Operations team
| Operations team
| 10 days before the upcoming deployment, inform the Noc-Managers.
| 10 days before the upcoming deployment, inform the Noc-Managers.
Update the ticket
Update the ticket.
|
|
|-
|-
| 7
| 7
| Service Provider team
| Service Provider team
| Schedule a downtime of the service in case it is needed
| Schedule a downtime of the service in case it is needed.
|
|
|-
|-
| 8
| 8
| Service Provider team
| Service Provider team
| Deploy release and update the ticket
| Deploy release and update the ticket.
| <br>
|
|-
|-
|9
|9
| Operations team
| Operations team
| Close the GGUS ticket after a week of the deployment only if the release was successful
| Close the GGUS ticket after a week of the deployment only if the release was successful.
|<br>
|
|}
|}


Line 145: Line 145:


An emergency release is the process of releasing one product, or a set of product, with the targeted goal of solve a specific problem that affects the EGI infrastructure. To qualify the problem for an emergency release the problem should be classified in at least one of the following categories:
An emergency release is the process of releasing one product, or a set of product, with the targeted goal of solve a specific problem that affects 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.


== Steps for emergency release ==
== Steps for emergency release ==
Line 165: Line 165:
*Release notes;
*Release notes;
*Justification of the need for an emergency release;
*Justification of the need for an emergency release;
* If the changes is one orginating from a Change Record tracked in an RT ticket as part of CHM, then add the link to the respective RT ticket for that change.
*If the release is one originating from one or multiple Change Records tracked in RT tickets as part of CHM, then add the links to the respective RT tickets.
|
|-
|-
| 2
| 2

Revision as of 18:10, 29 November 2018

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
Policy Group Acronym OMB
Policy Group Name Operations Management Board
Contact Group operations at egi.eu
Document Status FINAL
Approved Date
Procedure Statement The procedure describes the process of release and deployment of services and service components in EGI production infrastructure
Owner Owner of procedure


Overview

The procedure describes the process of release and deployment of service and service components in 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 tools from this list can be done by EGI central operations office, upon request, and every change is communicated to the OMB ML before being implemented. Please, open a GGUS ticket (ticket category: service request) to the Operations 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 tool
  • Operations team: Oversees all the process and may provide further people for testing the tool
  • Noc-Managers: they are informed regarding the release of the new tool and may provide further people for testing it

Requirements

The prerequisites are:

Acceptance criteria

A new release of a Tool 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 tool is usable in all its features
    • The interoperability with the other tools is not broken

Steps for the release a service or sercice component update

Responsible Action Notes
1 Service Provider team

Once release is ready the team opens a GGUS ticket (selecting category: Release) to Operations with the following information:

  • Name of the tool;
  • Date of release;
  • Release notes;
  • Suggested deployment date;
  • Testing instance url and testing instructions;
  • Names of testers if testing is manual (if not defined Development team may ask to appoint testers);
  • If the release is one originating from one or multiple Change Records tracked in RT tickets as part of CHM, then add the links to the respective RT tickets.
2 Operations Team
  • 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 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;
  • can add further people for performing the tests;
  • The suggested duration of the test phase is two weeks;
  • Update the ticket.
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 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 product, or a set of product, with the targeted goal of solve a specific problem that affects 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 release is ready the team opens a GGUS ticket (selecting category: Release) to Operations with the following information:

  • Name of the tool;
  • Date of release;
  • Release notes;
  • Justification of the need for an emergency release;
  • If the release is one originating from one or multiple Change Records tracked in RT tickets as part of CHM, then add the links to the respective RT tickets.
2 Operations Team
  • Acknowledge the need for an emergency release;
  • Update the ticket.
3 Service Provider team Record an unplanned downtime of the service in case it is needed.
4 Service Provider team Deploy 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 reorganize steps for normal releases.
Retrieved from "https://wiki.egi.eu/w/index.php?title=PROC23&oldid=100625"