Difference between revisions of "EGI Change Management"
Line 70: | Line 70: | ||
== Software Development changes == | == Software Development changes == | ||
Most changes that fall under the scope of CHM will likely be to production service delivery (e.g. upgrades, major hardware changes etc). However, changes may also be in the form of software development to production services. For example, if a user community requests new functionality from developers that requires 2 months of development effort, there may be a risk of insufficient funded effort, or reduced manpower elsewhere in the project. This can especially be the case if such development is unforeseen at the beginning of a project. In such cases, persons managing services are encouraged to bring such changes to the CAB for discussion, approval and appropriation of development effort. | Most changes that fall under the scope of CHM will likely be to production service delivery (e.g. upgrades, major hardware changes etc). However, changes may also be in the form of software development to production services. For example, if a user community requests new functionality from developers that requires 2 months of development effort, there may be a risk of insufficient funded effort, or reduced manpower elsewhere in the project. This can especially be the case if such development is unforeseen at the beginning of a project. In such cases, persons managing services are encouraged to bring such changes to the CAB for discussion, approval and (where appropriate) appropriation of development effort. | ||
== Full Procedure Documentation == | == Full Procedure Documentation == |
Revision as of 14:22, 31 March 2017
The EGI Change Management (CHM) Process Introduction
This is the homepage on the EGI Wiki of the EGI Change Management Process.
Ensuring effective change management within the EGI’s production IT environment is extremely important in ensuring high-quality delivery of IT services.
The purpose of the IT Change Management Policy is to manage changes in a planned and predictable manner in order to assess risks, assign resources, and minimize any potential negative impact to services. This is done by requiring change owners to prepare a Request for Change (File:Request+for+change+template.doc) where a set of standard questions regarding the change are answered and presented to the Change Advisory Board (CAB).
The CAB meets to assess and approve changes and is coordinated on the egi-cab@mailman.egi.eu mailing list. It consists of employees of the EGI Foundation including the Technical Director and members of the senior operations and management team.
Changes are tracked as RT tickets on the change-mgmnt queue, while people can submit a completed RfC (File:Request+for+change+template.doc) to: change-mgmnt@rt.egi.eu. The change risk (likelihood X impact) should then be evaluated by the Service Owner and recorded as custom fields on the ticket in preparation for the CAB review. Further details about evaluating risk may be found here: File:IMS-RMGuideline-060117-1020-4791.pdf.
Click https://documents.egi.eu/public/ShowDocument?docid=2944 for a presentation introducing the process.
Services that fall under Change Control
Service Title |
Person(s) Managing the Service |
EGI DataHub |
Lukasz Dutka, Barosz Kryza |
EGI AppDB |
Marios Chatziangelou |
Operations Portal |
Cyril L'Orphelin |
Service Monitoring - ARGO |
Christos Kanellopoulos |
Configuration Database - GOCDB |
David Meredith |
Helpdesk - GGUS |
Guenter Grein, Helmut Dres |
Accounting - Accounting repository (Computing and Grid) |
Adrian Coveney |
Accounting - Accounting Portal |
Iván Díaz Álvarez |
Messaging |
Christos Kanellopoulos |
Training Infrastructure |
Gergely Sipos |
Standard Changes
This is the list of standard, or pre-approved changes, listed by Service.
Helpdesk - GGUS
Title |
Description |
RT Ticket Reference |
Install patches on GGUS servers |
The installation of patches is required on all GGUS servers for keeping the system secure. |
RT#12262 |
Software Development changes
Most changes that fall under the scope of CHM will likely be to production service delivery (e.g. upgrades, major hardware changes etc). However, changes may also be in the form of software development to production services. For example, if a user community requests new functionality from developers that requires 2 months of development effort, there may be a risk of insufficient funded effort, or reduced manpower elsewhere in the project. This can especially be the case if such development is unforeseen at the beginning of a project. In such cases, persons managing services are encouraged to bring such changes to the CAB for discussion, approval and (where appropriate) appropriation of development effort.
Full Procedure Documentation
CHM procedure documentation is available on the EGI Confluence. These pages are only accessible to EGI Employees, so PDF versions of these pages are additionally available here:
File:IMS-Changemanagementpolicy-060117-1500-4793.pdf
File:IMS-CHM1Managechangesincludingemergencychanges-060117-1500-4795.pdf
File:IMS-CHM2Maintainthelist,descriptionsandstep-by-stepworkflowsforwell-knownandrecurringchanges-060117-1500-4797.pdf