Difference between revisions of "Maintenance Release Cycle procedure"

From Gcube Wiki
Jump to: navigation, search
(Introduction)
Line 4: Line 4:
  
 
=== Acronyms List ===
 
=== Acronyms List ===
Please refer to [[Procedure Release Cycle#Acronyms List|Acronyms List in Release Cycle]] section.
+
Please refer to [[Major/Minor Release Cycle procedure#Acronyms List|Acronyms List in Release Cycle]] section.
  
 
== Start of Maintenance Cycle ==
 
== Start of Maintenance Cycle ==
Maintenance Cycle starts when a ticket of type '''Software Incident''' with priority set at '''high''' is assigned to SA3 team. When they are created, all ''Software Incident'' tickets are assigned to [[Role Developer|Developers]] (who are in charge to fix the defect). After developer resolves the ticket, in case it has ''priority'': high, it assigned to SA3 that will start a new Maintenance Cycle to include patched component in production version of gCube.
+
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 patch version of gCube must be released following the Maintenance Release Cycle.
  
  
'''Note 1:''' ''priority'' is assigned by Support Team during [[Procedure Infrastructure Incident Management|Incident Management]] procedure. Actually, it is the Support Team that decide whether a Maintenance Cycle will be triggered or not.
+
'''Note 1:''' ''priority'' is assigned by Support Team during [[Procedure Infrastructure Incident Management|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.
 
'''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.
Line 17: Line 17:
 
== Maintenance Cycle Steps ==
 
== Maintenance Cycle Steps ==
  
Figure below shows the Maintenance Cycle workflow. All steps are described one by one in next sections. Mostly, steps in this procedure are equals to correspondent steps in [[Procedure Release Cycle|Release Cycle]]. In this case a reference to the correspondent step  section is provided. In case steps differs, a most detailed description is provided.
+
Figure below shows the Maintenance Cycle workflow. All steps are described one by one in next sections. Mostly, steps in this procedure are the same of correspondent steps in [[Major/Minor Release Cycle procedure|Release Cycle]]. In this case a reference to the correspondent step  section is provided. In case steps differs, a most detailed description is provided.
  
 
[[Image:Maintenance_cycle.png|center]]
 
[[Image:Maintenance_cycle.png|center]]

Revision as of 14:46, 12 January 2012

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 Release Cycle, but, in fact, it is - typically - simpler and faster since just one (or few) modules needs to be released and integrated in an already well tested and previously gCube version. Another good reason for which 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.


Acronyms List

Please refer to Acronyms List in Release Cycle section.

Start of Maintenance 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 patch 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.


Maintenance Cycle Steps

Figure below shows the Maintenance Cycle workflow. All steps are described one by one in next sections. Mostly, steps in this procedure are the same of correspondent steps in Release Cycle. In this case a reference to the correspondent step section is provided. In case steps differs, a most detailed description is provided.

Maintenance cycle.png


Preparing the Maintenance Cycle (RMan)

RMan follows same steps as in Release Cycle (see section Preparing the Release Cycle)

Additionally, RMan must forward ticket that triggered the Maintenance Cycle to Dev


Fixing defects (Dev)

The ticket is received by Dev, who:

  • switches to the suitable 'Maintenance Branch' in SVN (e.g. branches/org.gcube.1-1). This branch is already updated with the latest version running in production.
  • fixes the defects on the Maintenance Branch and port them the Trunk/HEAD if applicable


Delivering Components (Dev)

In this step Dev deliveries the "patched" component. This step is the same described in Delivering Components section of Release Cycle procedure


Release of a new ESC (SMan)

Also the fixed component's parent needs to be update. Procedure followed by SMan is the same described in Delivering Subsystems with an addition: the release tickets should include also a reference to the production_support ticket that triggered the Maintenance Cycle


Integration and Testing (RMan, TTeam)

The phase of integration and testing of EPC is conducted in the same way described in following steps of Release Cycle procedure:

Above steps are collapsed here in one section just for convenience' sake; actually they are executed in the same sequence and with the same transitions as in Release Cycle


Maintenance Cycle closure

Maintenance Cycle closure procedure is exactly the same as in Release Cycle procedure.