Difference between revisions of "Maintenance Release Cycle procedure"
From Gcube Wiki
(→Introduction) |
|||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | = Introduction = | |
| − | Maintenance Cycle aims to correct one or more defects discovered in a gCube software running in production infrastructure. A Maintenance Cycle is very similar to [[Major/Minor Release Cycle procedure|Release Cycle]], but, | + | Maintenance Cycle aims to correct one or more defects discovered in a gCube software running in production infrastructure. A Maintenance Cycle is very similar to a normal [[Major/Minor Release Cycle procedure|Release Cycle]], but it involves fewer components and, therefore, it is faster to integrate. It should be as short as possible (few days) since it is a reaction to a defect in production infrastructure and a "patched" version has to be released very quickly. |
| + | = Maintenance Cycle Steps = | ||
| + | Maintenance Cycle starts when an incident ticket is opened for a defect found in production and the ticket is classified as ''high priority''. Once developers resolves the defect, a new patched version of gCube must be released following the Maintenance Release Cycle. | ||
| − | + | '''Note 1:''' ''priority'' is assigned by Support Team during Incident Management procedure. Therefore, it is the Support Team that decide whether a Maintenance Cycle will be triggered or not. | |
| − | + | ||
| − | + | '''Note 2:''' other 'production_support' defects involving Developers and the Release Team (i.e. category:''Software Incident'' and priority:''low'') have to be fixed in the trunk/HEAD and will be delivered in production along with the next gCube release. | |
| − | + | ||
| − | + | Excepting for the trigger event, a Maintenance release cycle follows exactly the same steps of release preparation, integration and closure of a normal [[Major/Minor Release Cycle procedure|Release Cycle]]. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Latest revision as of 15:39, 22 October 2015
Introduction
Maintenance Cycle aims to correct one or more defects discovered in a gCube software running in production infrastructure. A Maintenance Cycle is very similar to a normal Release Cycle, but it involves fewer components and, therefore, it is faster to integrate. It should be as short as possible (few days) since it is a reaction to a defect in production infrastructure and a "patched" version has to be released very quickly.
Maintenance Cycle Steps
Maintenance Cycle starts when an incident ticket is opened for a defect found in production and the ticket is classified as high priority. Once developers resolves the defect, a new patched version of gCube must be released following the Maintenance Release Cycle.
Note 1: priority is assigned by Support Team during Incident Management procedure. Therefore, it is the Support Team that decide whether a Maintenance Cycle will be triggered or not.
Note 2: other 'production_support' defects involving Developers and the Release Team (i.e. category:Software Incident and priority:low) have to be fixed in the trunk/HEAD and will be delivered in production along with the next gCube release.
Excepting for the trigger event, a Maintenance release cycle follows exactly the same steps of release preparation, integration and closure of a normal Release Cycle.
