Difference between revisions of "Maintenance Release Cycle procedure"

From Gcube Wiki
Jump to: navigation, search
(Delivering Components (Dev))
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Introduction ==
+
= 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, 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.
+
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.
  
=== Acronyms List ===
+
'''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.
Please refer to [[Major/Minor Release Cycle procedure#Acronyms List|Acronyms List in Release Cycle]] section.
+
  
== Start of Maintenance Cycle ==
+
'''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 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. Therefore, it is the Support Team that decide whether a Maintenance Cycle will be triggered or not.
+
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]].
 
+
'''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 [[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]]
+
 
+
 
+
=== Preparing the Maintenance Cycle ([[Role Release Manager|RMan]]) ===
+
RMan follows same steps as in [Major/Minor Release Cycle procedure|Release Cycle]] (see section [[Major/Minor Release Cycle procedure#Preparing the Release Cycle (RMan)|Preparing the Release Cycle]])
+
 
+
Additionally, RMan must forward ticket that triggered the Maintenance Cycle to [[Role Developer|Dev]]
+
 
+
 
+
=== Fixing defects ([[Role Developer|Dev]]) ===
+
The ticket is received by [[Role Developer|Dev]], who:
+
* switches to the correct 'Maintenance Branch' in SVN (e.g. branches/org.gcube.1-1). This branch already contains the latest version running in production.
+
* fixes the defects on the Maintenance Branch and port them the ''Trunk/HEAD'' if applicable
+
 
+
 
+
=== Delivering Components ([[Role Developer|Dev]]) ===
+
In this step [[Role Developer|Dev]] deliveries the "patched" component. This step is the same described in [[Major/Minor Release Cycle procedure#Delivering_Components_.28Dev.29|Delivering Components ]] section of [[Major/Minor Release Cycle procedure|Release Cycle]] procedure
+
 
+
=== Release of a new ESC ([[Role Subsystem Manager|SMan]]) ===
+
Also the fixed component's parent needs to be update. Procedure followed by [[Role Subsystem Manager|SMan]] is the same described in [[Major/Minor Release Cycle procedure#Delivering Subsystems (SMan)|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 ([[Role Release Manager|RMan]], [[Role Tester|TTeam]]) ===
+
The phase of integration and testing of EPC is conducted in the same way described in following steps of [[Major/Minor Release Cycle procedure|Release Cycle]] procedure:
+
* [[Major/Minor Release Cycle procedure#Update EPC (RMan)|Update EPC]]
+
* [[Major/Minor Release Cycle procedure#Building (RMan)|Building]]
+
* [[Major/Minor Release Cycle procedure#Deployment Testing (TTeam)|Deployment Testing]]
+
* [[Major/Minor Release Cycle procedure#Functional Testing (TTem)|Functional Testing]]
+
 
+
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 [[Major/Minor Release Cycle procedure#Release and Distribution|Release Cycle]] procedure.
+

Latest revision as of 14: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.