Difference between revisions of "Maintenance Release Cycle procedure"
| 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 a normal[[Major/Minor Release Cycle procedure|Release Cycle]], but, it involves fewer components and it is faster. It should be as short as possible (few days) is that, since it is a reaction to a defect in production infrastructure, "patched" version has to be released very quickly. | + | 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 it is faster. It should be as short as possible (few days) is that, since it is a reaction to a defect in production infrastructure, "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. | 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. | ||
| Line 14: | Line 10: | ||
| − | + | 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]]. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Revision as of 15:43, 13 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 it is faster. It should be as short as possible (few days) is that, since it is a reaction to a defect in production infrastructure, "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.
