Difference between revisions of "Major/Minor Release Cycle procedure"

From Gcube Wiki
Jump to: navigation, search
(→‎Building (RMan))
(→‎Release Integration)
 
(165 intermediate revisions by 4 users not shown)
Line 1: Line 1:
−
== Introduction ==
+
= Acronyms List =
−
 
+
−
This section describes the Release Cycle procedure focusing on activities to be executed and roles involved. The figure below shows how procedure have been split up in several activities. Each activity involves only one role and provide the input for the subsequent activity.
+
−
 
+
−
[[Image:Release_cycle.png|center]]
+
−
 
+
−
 
+
−
In the description of steps below, knowledge of the ETICS datamodel (e.g. the concepts of project, subsystems, components, configurations) is assumed.
+
−
 
+
−
As a rough definition, we can say that a '''project''' is composed of '''subsystems''', which is further organized in '''components'''. These are generically termed  '''modules'''. A specific version of a module is called '''configuration'''. Further details about ETICS can be found in the [[SA3 Tools Etics|Tools/ETICS]] section.
+
−
 
+
−
 
+
−
=== Acronyms List ===
+
  
 
{| border="0" cellpadding="4" cellspacing="0"  
 
{| border="0" cellpadding="4" cellspacing="0"  
 
|-
 
|-
−
| '''EPC''' || ETICS Project Configuration (e.g. org.gcube.1-6-0)
+
| '''CRT''' || Component Release Ticket
 
|-
 
|-
−
| '''ESC''' || ETICS Subsystem Configuration (e.g. org.gcube.annotation-management.1-1-0)
+
| '''EPC''' || [[ETICS|ETICS]] Project Configuration (e.g. org.gcube.1-6-0)
 
|-
 
|-
−
| '''ECC''' || ETICS Component Configuration (e.g. org.gcube.annotation-management.abe.1-1-0)
+
| '''ESC''' || [[ETICS|ETICS]] Subsystem Configuration (e.g. org.gcube.annotation-management.1-1-0)
 +
|-
 +
| '''ECC''' || [[ETICS|ETICS]] Component Configuration (e.g. org.gcube.annotation-management.abe.1-1-0)
 
|-
 
|-
 
| '''Dev''' || [[Role Developer|Developer]] role
 
| '''Dev''' || [[Role Developer|Developer]] role
 +
|-
 +
| '''PRT''' || Project Release Ticket
 
|-
 
|-
 
| '''SMan''' || [[Role Subsystem Manager|Subsystem Manager]] role
 
| '''SMan''' || [[Role Subsystem Manager|Subsystem Manager]] role
 +
|-
 +
| '''SRT''' || Subsystem Release Ticket
 
|-
 
|-
 
| '''RMan''' || [[Role Release Manager|Release Manager]] role
 
| '''RMan''' || [[Role Release Manager|Release Manager]] role
Line 30: Line 24:
 
|}
 
|}
  
−
== Start of a Release Cycle ==
+
= Introduction =
−
Release Cycles aim to release a new major or minor version of gCube software '''providing a set of new functionalities'''. Release Cycle can start only when all expected functionalities targeted for the release are available in the trunk branch of gCube SCM Repository. Deadlines to start a cycle, deliver components, integrate and test candidate configurations and close the cycle are made available in the gCube [[Release Plan|Release Plan]].
+
−
 
+
−
 
+
−
== Release Cycle Steps ==
+
−
 
+
−
 
+
−
=== Preparing the Release Cycle ([[Role Release Manager|RMan]]) ===
+
−
This step is in charge to [[Role Release Manager|RMan]] (also responsible for deciding the start time) who:
+
−
# '''create a new EPC''' for the upcoming gCube version. For convenience, it will be cloned by the latest EPC
+
−
# schedule '''automatic integration builds''' for the new EPC
+
−
# create a '''new milestone''' on the [[SA3 Tools Trac|Trac]] system
+
−
# establishes a '''deadline for the submission''' of release tickets (typically 1-2 weeks)
+
−
# '''notify by email''' [[Role Subsystem Manager|SMans]] and [[Role Developer|Devs]] about the starting of the new release cycle and deadline for submission. Notification email should include also a list of new/upgraded subsystems expected and a list of new features/changes
+
−
 
+
−
 
+
−
=== Delivering Components ([[Role Developer|Dev]]) ===
+
−
If a new version for a component is expected for the upcoming release (or if a [[Role Developer|Dev]] wants to release a new version of his component), the [[Role Developer|Dev]] has in charge the delivery of his component(s). Steps he must follows in order to delivery his component are:
+
−
 
+
−
# if version to delivery has major and/or minor changes
+
−
#*'''create a release branch''' respecting all contemplated [[Gcube subversion repository|conventions]]
+
−
#** developers should insert a meaningful comment (list of changes/features) when execute branching operation in order to make possible automatic generation of Release-Log files
+
−
#* otherwise (in case of delivery of a patch version) no release branch has to be created and the proper release branch must be used
+
−
#'''create a new ECC''' (possibly by cloning) for his component. The ECC must:
+
−
#* respect all the [[Naming Conventions|Naming Conventions]]
+
−
#* '''''tag'' property must point to the proper release branch in SVN repository''' (e.g. branches/ext/hibernate-servicearchive/3.2@19387)
+
−
#* advertise changes though a proper increase of the version number
+
−
# '''build remotely''' (at least one time) the ECC in the context of the newly created EPC in which it will be included
+
−
#* if build is successful then go to step 3
+
−
#* else resolve problems, update the ECC and go back to step 2
+
−
# '''communicate to [[Role Subsystem Manager|SMan]]''' (no means established for this notification) that ECC is ready to be included in subsystem configuration. This communication has to report the activities that led to the new ECC in terms of the tickets (defects, enhancements, tasks) number. Those tickets are expected to be associated with the 'Ready To Release' milestone clearly.
+
−
 
+
−
 
+
−
Please note that these step are needed only if a new version of the component has to be released. Otherwise the ECC used for the Release Cycle will be the same included in the latest gCube version.
+
−
 
+
−
If the component is discontinued, the [[Role Developer|Dev]] must ask the [[Role Subsystem Manager|SMan]] to remove the ECC from the ESC.
+
−
 
+
−
=== Delivering Subsystems ([[Role Subsystem Manager|SMan]]) ===
+
−
In D4Science-II data model, Subsystems are aggregation of modules. If new ECCs are created for one or more modules in a subsystem, then parent Subsystems have to be released too.
+
−
 
+
−
These are the steps in charge to [[Role Subsystem Manager|SMan]] to release a new ESC:
+
−
# '''receives notification from Devs''' about new ECCs avaiability in the scope of his subsystem
+
−
# '''creates a new ESC''' (by cloning the previous one)
+
−
# substitutes old ECCs with new ones
+
−
# '''builds new ESC remotely''' (on ETICS infrastructure) in the context of the newly created EPC
+
−
#* if the build is successful then go to step 5
+
−
#* else notify Devs, who will update their ECCs, and go back to step 3
+
−
# '''creates a release ticket''' announcing the ESC release (see below) by reporting also the tickets number describing the activities performed to achieve the ECCs belonging to the ESC. The ticket numbers have to be reported in the Blocking field of the release ticket.
+
−
 
+
−
 
+
−
Please note that these step are needed only if a new version of a subsystem has to be released. If no new ESC is planned for the upcoming gCube version (e.g. no new ECCs in the subsystem), no actions are needed (the ESC used for the release cycle will be the same included in the latest gCube version).
+
−
 
+
−
 
+
−
==== Creating a release ticket ====
+
−
 
+
−
When a new ESC is available, [[Role Subsystem Manager|SMan]] must create a ''release ticket'' on [[Trac|Trac system]] to press [[Role Release Manager|RMan]] to include new ESC in the EPC.
+
−
 
+
−
''Release ticket'' is a ticket with these properties:
+
−
{| border="0" cellpadding="4" cellspacing="0"
+
−
|-
+
−
|-
+
−
| '''summary''' || "[ESC-name] available for release"
+
−
|-
+
−
| '''description''' || ''free text. <u>Must include at least the list of new (and only new) ECCs</u>''
+
−
|-
+
−
| '''type''' || "release"
+
−
|-
+
−
| '''Milestone''' || [EPC-name]
+
−
|-
+
−
| '''Status''' || "available"
+
−
|-
+
−
| '''Subsystem''' || [Subsystem-name]
+
−
|-
+
−
| '''Subsystem Configuration''' || [ESC-name]
+
−
|-
+
−
| '''Assign to''' || ''[[Role Release Manager|RMan]]''
+
−
|-
+
−
| '''Blocking''' || ''comma-separated list of blocking tickets (see above)'' (e.g. "123, 437, 765")
+
−
|}
+
−
 
+
−
 
+
−
An example of creation of a '''valid release ticket''' follows.
+
−
 
+
−
[[Image:Release-ticket.png|center|frame]]
+
−
 
+
−
=== Update EPC ([[Role Release Manager|RMan]]) ===
+
−
[[Role Release Manager|RMan]] recives ''release tickets'' and does following steps in order to integrate new ESC in the upcoming release:
+
−
# '''receives''' ''release ticket'' from SMan
+
−
# '''updates the EPC''' accordingly to ''release tickets''
+
−
# forward release ticket to the [[Role Release Manager|RMan]] changing the status: '''Available --> Ready to Build'''
+
−
 
+
−
From this moment on, the ESC (and its components) will be built among other components during EPC builds (see below).
+
−
 
+
  
−
Release ticket without software validation report or not satisfactory software validation reports are rejected and the ESC is not added to the EPC.
+
This section describes the Release Cycle procedure focusing on activities to be executed and roles involved. The release cycle is supported and partially automated by several tools described in details in section [[Release_Tools|Tools]]. In particular, the [[Redmine|Tracking System]] has a central role in the procedure because all activities and communications between actors are done using tickets (PRT, SRT, CRT). This assures the full traceability of the status and history of single components being released.  
  
 +
The new procedure has been thought to change the current practices and improve the exploitation of the resources:
 +
 
 +
a) the application developers can build against the gCube staging repository. It contains always stable software code suitable for build applications, services, methods, etc. ready for the production infrastructure
 +
 
 +
b) the application developers can test their stable version of their applications on the pre-production infrastructure. 
 +
 
 +
c) the developers of the enabling technologies will have to use the development infrastructure for their development and release stable (even if not complete) versions of their software as soon as they have tested it. Since the release cycle is always open, multiple releases of the same enabling component in a release cycle are expected.
 +
 
  
−
=== Building ([[Role Release Manager|RMan]]) ===
+
Some improvements are introduced :
 +
* fixed time releases: the new release cycle will have a fixed duration of a 6 weeks:
 +
*# no pauses between releases;
 +
*#different deadlines during the release for different type of components based on the components grouping;
 +
*#preprod upgrade, testing and production upgrade activities start earlier in the release cycle.The rule will be:
 +
<div align='center'>
 +
'''As soon as a component build successfully it must be deployed on preprod and then in production'''
 +
</div>
 +
* better components grouping: the components will be grouping in three groups:
 +
*#'''tier-1''': enabling (in the legacy/gCore meaning). For example : ghn-bundle, smartgears-bundle, authz, accounting, home-library and so on.
 +
*#'''tier-2''': services and portlets internal to gCube. For example : DataMiner, SPD, TabularData, User Management Portlet and so on.
 +
*#'''tier-3''': apps developed by gCube community (BluePillars WPs). For example : Simulfish-growth, GeoAnalytics and so on.
 +
* better procedure and tools for pre-prod upgrade. Having this three groups, allows to start pre-prod upgrade and production upgrade earlier in the release cycle:
 +
*# "Enabling" components will freeze after two weeks from the start of the release and will be tested in pre-prod immediately after
 +
*#"Common Apps" components will be frozen the 4th week of the release: no need for waiting for all other components.
 +
They will be tested in pre-prod as soon as they build successfully in ETICS and will be deployed.
 +
They can be deployed in production when the testing phase ends.
 +
*#"Community Apps" components will be the latest ones and will be able to exploit the pr-eprod infra upgraded to the current release to finish the development and for the testing:they will be tested and deployed in production as soon as they are ready.
  
−
Through this activity, EPC configuration is built until all modules are free from ''integration defects''. Build activity is better explained in the section [[Continuous Build and Integration#Build Activity|Build Activity]]. These are, briefly, main steps:
+
The following figure shows the Release Gant for the new procedure:
 +
[[File:ReleaseGant.jpg|center|frame|ReleaseGant Release Cycle]]
  
−
* '''EPC is automatically built twice a day''' (at 00:00 CET and 11:00 CET, see this [[Continuous Integration procedure#Time Table|Time Table]] for details) using the Building Infrastructure
+
<br>
−
* during the build process a number of reports are generated in order to check components' compliance with settled guidelines and requirements (e.g. findbugs and checkstyle plugins, sa-certification, checking of component versions correspondence)
+
In the new release procedure the pre-prod infrastructure will be used also for development of community apps.This environment should remain stable. At the same time it must have candidate release versions of componentsrequire to re-deploy every time a new version is released and integrates fine in the release.
−
* reports and logs become available on [[BTRT|BTRT]] application as soon as build ends up
+
<br>
 +
The procedure for the pre-prod update will be:
 +
*Deployment of a service is triggered by :
 +
**X → “Under Integration” status change in release tickets. E.g.:
 +
***Available → “Under Integration”
 +
***Build Issue → “Under Integration”
 +
***RTD on Preprod -> Deployed on Preprod
 +
***Deployed on Preprod → “Under Integration”
 +
*New artifact available in nexus gcube-staging with a RN matching the one of the ETICS config.
 +
<br>
 +
The notation used in the following sections to describe the updates to the tickets is: <code>{field1: value1, field2: value2, ..., fieldN: valueN}</code>. It lists the fields to be updated in the ticket and the corresponding value to use.
 +
<br>
  
 +
= Release Preparation =
  
−
For each executed EPC build, [[Role Release Manager|RMan]]:
+
In order to integrate a gCube release, some '''preparatory steps''' (performed by the [[Role_Release_Manager|RMan]]) are needed to to setup the [[Release Tools|Tools]] that supports the integration activities:
−
# looks for integration defects (see below)
+
# [[Role_Release_Manager|RMan]] creates a ''Sprint'' on the [[Redmine|Tracking System]] for the release (e.g. "Release gCube 3.9.0")
−
# if integration defects are discovered, open ''integration defect tickets''
+
# [[Role_Release_Manager|RMan]] creates the PRT <code>{name: <EPC-Name>, status: New, sprint: <Release-Sprint>}</code>
−
# with regard to ''integration defect tickets'' opened for the previous build, if defects are solved in the current build, close them
+
# [[Role_Release_Manager|RMan]] creates the EPC cloning it from org.gcube.HEAD
−
# if the build is successful change status of ''release tickets'' (if not yet done) from '''Ready to Build''' --> '''Ready to DT''' (this will trigger Deployment Testing activity)
+
# [[Role_Release_Manager|RMan]] updates the PRT <code>{status: New -> Available}</code>
  
  
−
Build activity last until all components are free from integration defects. Next sub-sections will explains how to find integration defects and how to react to them.
+
The steps needed to '''release a new version of a component''' are:
  
 +
(N.B.: steps from 7 to 10 might be not necessary if other components have been already delivered in the same subsystem for the current release)
 +
<br>
 +
<ol>
 +
<li> [[Role_Developer|Dev]] creates a CRT to advertise the release on the [[Redmine|Tracking System]]. This is useful for other Developers that depends on the component to know that their components might need an update in the release. <code>{name: <EPC-Name>, status: New, sprint: <Release-Sprint>, Assignee: <Dev>, Parent Task: <SRT>}</code>. The status of the CRT is ''New'' at this time and the ECC is not yet available.
  
−
==== Discovering Integration Defects ([[Role Release Manager|RMan]], [[Role Developer|Dev]]) ====
+
The Release Tickets is update to include the component type. In particular, the Enabling field has been removed and it has been replaced by the "Type" field (as shows in the following figure) with the following choices: Grouping, Enabling, Common Apps, Community Apps. When a release ticket is created, a value must be selected accordingly with the component type.  
−
If a module do not build successfully in the context of EPC builds, most likely it has integration defects (assuming it builds in isolation in the development environment; otherwise it should not be released at all). ''Integration defects'' are related commonly to errors/oversights in:
+
−
* dependencies definition
+
−
* naming
+
−
* checkout/build commands
+
−
* environment definition
+
−
* for ServiceArchives, profile.xml definition (will raise certification defects)
+
  
 +
[[File:TypeField.jpg|center|frame|Type Grouping]]
  
−
The first place to discover integration defect is '''[[SA3 Tools BTRT|BTRT]]'''. BTRT was designed and implemented exactly to make it easier to discover ''integration defects'' and their cause, providing a graphic interface that helps to quickly identify components with integration defects and a number of reports and logs to find their cause.
 
  
−
[[Role Developer|Devs]] should, as frequently as they can, look at latest builds in BTRT in order to identify integration defects in their components and fix them.
+
</li>
 +
<li> If SRT does not exists when CRT is created (i.e. first component released in the Subsystem), [[Role_Developer|Dev]] also creates the SRT: <code>{name: <ESC-Name>, status: New, sprint: <Release-Sprint>, Assignee: <SMan>, Parent Task: <PRT>}</code>.
 +
</li>
 +
<li> When the [[Role_Developer|Dev]] has created the ECC and he/she has verified that it's complete and build successfully, [[Role_Developer|Dev]] updates the CRT: <code>{status: New -> Available, Watcher: <SMan>}</code>. Please note that [[Role_Developer|Dev]] adds the [[Role Subsystem Manager|SMan]] as a watcher of the CRT; in this way [[Role Subsystem Manager|SMan]] is notified that the ECC is ready to be attached to the ESC.
 +
</li>
 +
<li> [[Role Subsystem Manager|SMan]] creates the ESC and attaches the ECC to the ESC.
 +
</li>
 +
<li> [[Role Subsystem Manager|SMan]] updates the CRT: <code>{status: Available -> Under Integration}</code>.
 +
</li>
 +
<li> [[Role Subsystem Manager|SMan]] updates the SRT: <code>{status: New -> Available, Watchers: <RMan>}</code>. Please note that [[Role Subsystem Manager|SMan]] adds the [[Role Release Manager|RMan]] as a watcher of the SRT; in this way [[Role Release Manager|RMan]] is notified that the ESC is ready to be attached to the EPC.
 +
</li>
 +
<li> [[Role Release Manager|RMan]] attaches the ESC to the EPC.
 +
</li>
 +
<li> [[Role Release Manager|RMan]] enables on BTRT the ''Candidate Builds'' for the gCube release.
 +
</li>
 +
<li> [[Role Release Manager|RMan]] updates the SRT:  <code>{status: Available -> Under Integration}</code>.
 +
</li>
 +
<li> [[Role Release Manager|RMan]] activate the continuous integration of the EPC.
 +
</li>
 +
<li> [[Role Release Manager|RMan]] updates the PRT:  <code>{status: Under Integration}</code>.
 +
</li>
 +
</ol>
 +
<br>
  
−
In case there is a "persistent" integration defect, [[Role Release Manager|RMan]] open a ''integration defect ticket'' in the [[SA3 Tools Trac|Trac]] system. The ''integration defect ticket'' (assigned to the component's Dev) should clearly indicate the defect (if [[Role Release Manager|RMan]] can guess it) and link all useful reports/logs in BTRT.
+
[[File:Release ticket.png|center|frame|Example of CRT]]
  
 +
= Release Integration =
 +
Once the ECC of a component has been attached to the EPC, it will be part of the integration and testing activates to make sure the component integrates successfully with the gCube system and satisfies the gCube quality assurance policies. In this phase, the CRT will be used to report issues related to the component integration.
  
−
==== Resolving Integration Defects ([[Role Release Manager|RMan]], [[Role Developer|Devs]]) ====
+
[[Role Release Manager|Release Manager]] and [[Role Tester|Tester]] are responsible to look at reports and logs of BTRT builds to identify issues. In case of building issues:
 +
# the [[Role Release Manager|Release Manager]] updates the CRT: <code>{status: Under Integration -> Build Issue, comment: <issue description>}</code>. The comment should always include a link to a relevant log/report file.
 +
# The [[Role_Developer|Dev]] is notified of the issue and fixes it.
 +
# Once the issue is solved, the [[Role_Developer|Dev]] updates the CRT: <code>{status: Build Issue -> Under Integration, comment: <solution description>}</code>
 +
# [[Role Release Manager|Release Manager]] verify that the issue has been solved
  
−
Resolving integration defects is in charge to [[Role Developer|Devs]]. Fix the defect usually involve changes in ECC configuration (e.g. fix a misspelled ETICS dependency). In some complex cases, to fix the defect changes in component's source code are required. In the latter case, <u>it is very important that [[Role Developer|Dev]] does not forget to update the SVN revision number in ''tag'' field of the ECC, making it pointing at latest source code version!</u>
+
Same steps applies also for other deployment or functional issues. In these case different statuses will be used: ''DT Issue'' for deployment testing issues and ''FT Issue'' for functional testing issues.
  
−
Once ECC has been updated, next EPC build is awaited (or, in case time for releasing is running out, an EPC build can be launched manually by [[Role Release Manager|RMan]]). If ECC build successfully in the new EPC build then the "integration defect ticket" is closed.
+
While here it is assumed the [[Role Release Manager|Release Manager]] as the reporter of issues, also other actors involved in the release procedure (i.e. [[Role Developer|Dev]], [[Role Subsystem Manager|SMan]], [[Role Tester|Tester]]) can report issues.
  
−
It can be argued that this procedure could not work if the defect is notified when development has already progressed. However, the procedure is compatible with this situation as it relies on the assumption that Trunk/HEAD should not contain destabilizing changes that doesn't allow to fix and release.
+
In case of complex issues and/or issues that involves multiple components, the reporter can choose to open a new ticket on the [[Redmine|Tracking System]] instead of using the CRT.
  
−
=== Deployment Testing ([[Role Tester|TTeam]]) ===
+
[[File:Build_issue_ticket.png|center|frame|Example of a CRT updates in case of a build issue (see the History section)]]
−
Deployment Tests are carried out on artefacts produced by Build Activity. This activity is triggered from status change in ''release tickets''.
+
  
−
These are steps in charge to [[Role Tester|TTeam]] when a Deployment Testing Session is carried out:
+
Before to close the Release and after that the Release Manager updates the CRT in "Under Integration", an additional steps is provided. The introduction of the splitting of the release, the developers can deploy the candidate release artefact immediately on pre-production and then test them. After that ,  the deploy and testing phase for the not enabling component can start, as reported in the following steps:
−
# carry out deployment testing on artefacts in the latest EPC build
+
−
# generate a dt_report and publish it to the DTRepository. That report will be downloaded and become accessible from within BTRT (see [[SA3 Building Infrastructure#Fetch_Server|Fetch Server]] section for further details)
+
−
# in case some defects are revealed during deployment tests execution, open new ''testing defect tickets''
+
−
# close ''testing defect tickets'' solved in the current deployment tests execution
+
−
# if Deployment Testing Session is successful, change status of release tickets (if not yet done) from Ready to DT --> Ready to FT (this will trigger Functional Testing activity)
+
  
−
Typically, for each build a Deployment Testing session is carried out on build artefacts. A more detailed description of Deployment Testing activity can be found in the section [[SA3 Deployment Testing Activity|Deployment Testing Activity]]
+
# the Infrastructure Manager :update the CRT  <code>{status: Under Integration -> RTD on Preprod}</code>.It indicates that the component has been published on stagin nexus repository (by explicitly launching an ETICS build on the current release or because the night build succeeded, more details in '''STAGING NOTE''').This is used to notify the portal manager or the preprod infrastructure manager to upgrade that component on preprod, in this case they MUST be added in advance as watcher of the component release ticket (more details in '''PROVISIONING NOTE'''). This status MUST not be used for subsystem release ticket or the master release ticket.
 +
# Developer updates the CRT status : <code>{status: RTD on Preprod -> Deployed on Preprod}</code>. It indicates that the developer updated the component autonomously in the pre-production infrastructure .
 +
# Deployer or Pre-Prod Infrastructure Manager updates the CRT  <code>{status: RTD on Preprod -> Deployed on Preprod}</code>. It indicates that the component has been deployed on ALL nodes of preproduction and is up and running.
 +
#Tester Manager, after all portlets are tested (all Software Tested Ticket are "Tested on Preprod":[https://wiki.gcube-system.org/gcube/Functional_Testing Functional Testing Procedure]) updates the Release Ticket CRT <code>{status: Deployed on Preprod -> Tested on Preprod}</code> . The developer and/or the portal manager or the preprod infrastructure manager are confident that the component behave as expected and can be released as is.
  
 +
== STAGING NOTE ==
  
−
==== Reacting to Deployment Testing Defects ([[Role Developer|Devs]]) ====
+
In the nexus configuration is added the build number on staging repository.
−
When a defect is discovered in the deployment of a component during deployment testing, [[Role Tester|TTeam]] opens a ''testing defect ticket'' assigning it to component's Dev. Procedure to solve and close the defect is the same applied in [[Procedure Release Cycle#Resolving Integration Defects (RMan, Devs)|Resolving Integration Defects]].
+
Developers, Deployer and/or pre-prod Infrastructure Manager  must download the component to deploy
 +
(both in dev and pre-prod infrastructure) , from Nexus repository, having the build number.
  
 +
== PROVISIONING NOTE ==
  
−
=== Functional Testing ([[Role Tester|TTeam]]) ===
+
When any component needs to be deployed, an automatic procedure
−
Functional Tests are carried out on artefacts produced by Build Activity. This activity is triggered from status change in ''release tickets''. Functional Tests are executed against software deployed in [[SA3 Testing Infrastructure|Testing Infrastructure]]. Software is installed in Testing Infrastructure during Deployment Testing sessions.
+
by using provisioning ('''ANSIBLE''') '''MUST''' be created in advance.  
 +
The first time this situation is verified, the developer '''MUST''' create a ticket for provisioning support.  
 +
The ticket for provisioning '''MUST''' be related to the release ticket. The ticket can only be closed when
 +
(all the bullet must be verified):
  
 +
# the provisioning script has completed (by the developer or by the entitled people);
  
−
These are steps in charge to [[Role Tester|TTeam]] when a Functional Testing Session is carried out:
+
# a documentation regarding the script has to be created. The infrastructure and provisioning documentation lives here: https://support.d4science.org/projects/aginfraplut/wiki
−
# carry out functional testing on software deployed in testing infrastructure
+
−
# generate a ft_report and publish it to the FTRepository. That report will be downloaded and become accessible from within BTRT (see [[SA3 Building Infrastructure#Fetch_Server|Fetch Server]] section for further details)
+
−
# in case some defects are revealed during functional tests execution, open new ''testing defect tickets''
+
−
# close ''testing defect tickets'' solved in the current functional tests execution
+
−
# if Functional Testing Session is successful, change status of release tickets (if not yet done) from Ready to FT --> Ready to Release
+
  
−
A more detailed description of Functional Testing activity can be found in the section [[SA3 Functionality Testing Activity|Functionality Testing Activity]]
+
# the ticket has been updated indicating where the provisioning script is available and where is the documentation.
  
 +
Only when the provisioning ticket is closed the RTD on Preprod status can be set.
  
−
==== Reacting to Functional Testing Defects ([[Role Developer|Devs]]) ====
+
= Release Closure =
−
When a defect is discovered in component during functionality testing, [[Role Tester|TTeam]] opens a ''testing defect ticket'' assigning it to component's Dev. In the ticket a link to any useful report generated during testing session should be provided. Procedure to solve and close the defect is the same applied in [[Procedure Release Cycle#Resolving Integration Defects (RMan, Devs)|Resolving Integration Defects]].
+
When all components expected for a release have been delivered and all building, deployment and functional issues have been solved, the release can be considered closed and the components distributed.
  
 +
In order to close the release, these preparatory steps must be performed:
 +
# [[Role_Release_Manager|RMan]] sets the option "Include in searchers" of gCube Staging repository to ''false''
 +
# [[BTRT|BTRT]] continuous build type is set to ''Release build''. In this way, BTRT will publish the artifacts of the next build into the gCube Release Repository.
  
−
=== Release Cycle closure ===
 
  
−
When the [[Role Tester|TTeam]] is satisfied with the software, the latter can be released to production. This, final, step is in charge to the [[Role Release Manager|RMan]] who:
+
When all artifacts are published on the gCube Release Repository - i.e., after a 100% successful ''Release build'' - (a single build should be needed):
−
* locks the EPC as it was at the time of latest build
+
# [[Role_Release_Manager|RMan]] updates the [[Software Integration and Distribution: Release Log|Release Log]]
−
* create a branch in SVN repository making a snapshot of released software for future maintenance release
+
# [[Role_Release_Manager|RMan]] creates the Release Notes page (using XML Release notes)
−
* close all release tickets [status: released, resolved as: fixed]
+
# [[Role_Release_Manager|RMan]] disables the [[BTRT|BTRT]] builds
−
* update relase log page ([[Release Log|link]])
+
# [[Role_Release_Manager|RMan]] open a ticket to generate release description to include in the distribution page
−
* announce officially gCube version (indicating features) through d4science-ii news system
+
# [[Role_Release_Manager|RMan]] sets the option "Include in searchers" of gCube Staging repository to ''true''
 +
# [[Role_Release_Manager|RMan]] closes all release tickets (PRT, SRT, CRT) associated with closed release: <code>{status: Tested on Preprod -> Released}</code>. In case a component has been excluded from the release (e.g. unsolved integration issues, delays in the delivery) the CRT is udpdated with status ''Removed'' <code>{status: Under Integration -> Removed}</code>
 +
# [[Role_Release_Manager|RMan]] creates a tag svn for the entire released code

Latest revision as of 14:37, 6 April 2017

Acronyms List

CRT Component Release Ticket
EPC ETICS Project Configuration (e.g. org.gcube.1-6-0)
ESC ETICS Subsystem Configuration (e.g. org.gcube.annotation-management.1-1-0)
ECC ETICS Component Configuration (e.g. org.gcube.annotation-management.abe.1-1-0)
Dev Developer role
PRT Project Release Ticket
SMan Subsystem Manager role
SRT Subsystem Release Ticket
RMan Release Manager role
TTeam the set of Testers

Introduction

This section describes the Release Cycle procedure focusing on activities to be executed and roles involved. The release cycle is supported and partially automated by several tools described in details in section Tools. In particular, the Tracking System has a central role in the procedure because all activities and communications between actors are done using tickets (PRT, SRT, CRT). This assures the full traceability of the status and history of single components being released.

The new procedure has been thought to change the current practices and improve the exploitation of the resources:

a) the application developers can build against the gCube staging repository. It contains always stable software code suitable for build applications, services, methods, etc. ready for the production infrastructure

b) the application developers can test their stable version of their applications on the pre-production infrastructure.

c) the developers of the enabling technologies will have to use the development infrastructure for their development and release stable (even if not complete) versions of their software as soon as they have tested it. Since the release cycle is always open, multiple releases of the same enabling component in a release cycle are expected.


Some improvements are introduced :

  • fixed time releases: the new release cycle will have a fixed duration of a 6 weeks:
    1. no pauses between releases;
    2. different deadlines during the release for different type of components based on the components grouping;
    3. preprod upgrade, testing and production upgrade activities start earlier in the release cycle.The rule will be:

As soon as a component build successfully it must be deployed on preprod and then in production

  • better components grouping: the components will be grouping in three groups:
    1. tier-1: enabling (in the legacy/gCore meaning). For example : ghn-bundle, smartgears-bundle, authz, accounting, home-library and so on.
    2. tier-2: services and portlets internal to gCube. For example : DataMiner, SPD, TabularData, User Management Portlet and so on.
    3. tier-3: apps developed by gCube community (BluePillars WPs). For example : Simulfish-growth, GeoAnalytics and so on.
  • better procedure and tools for pre-prod upgrade. Having this three groups, allows to start pre-prod upgrade and production upgrade earlier in the release cycle:
    1. "Enabling" components will freeze after two weeks from the start of the release and will be tested in pre-prod immediately after
    2. "Common Apps" components will be frozen the 4th week of the release: no need for waiting for all other components.

They will be tested in pre-prod as soon as they build successfully in ETICS and will be deployed. They can be deployed in production when the testing phase ends.

    1. "Community Apps" components will be the latest ones and will be able to exploit the pr-eprod infra upgraded to the current release to finish the development and for the testing:they will be tested and deployed in production as soon as they are ready.

The following figure shows the Release Gant for the new procedure:

ReleaseGant Release Cycle


In the new release procedure the pre-prod infrastructure will be used also for development of community apps.This environment should remain stable. At the same time it must have candidate release versions of componentsrequire to re-deploy every time a new version is released and integrates fine in the release.
The procedure for the pre-prod update will be:

  • Deployment of a service is triggered by :
    • X → “Under Integration” status change in release tickets. E.g.:
      • Available → “Under Integration”
      • Build Issue → “Under Integration”
      • RTD on Preprod -> Deployed on Preprod
      • Deployed on Preprod → “Under Integration”
  • New artifact available in nexus gcube-staging with a RN matching the one of the ETICS config.


The notation used in the following sections to describe the updates to the tickets is: {field1: value1, field2: value2, ..., fieldN: valueN}. It lists the fields to be updated in the ticket and the corresponding value to use.

Release Preparation

In order to integrate a gCube release, some preparatory steps (performed by the RMan) are needed to to setup the Tools that supports the integration activities:

  1. RMan creates a Sprint on the Tracking System for the release (e.g. "Release gCube 3.9.0")
  2. RMan creates the PRT {name: <EPC-Name>, status: New, sprint: <Release-Sprint>}
  3. RMan creates the EPC cloning it from org.gcube.HEAD
  4. RMan updates the PRT {status: New -> Available}


The steps needed to release a new version of a component are:

(N.B.: steps from 7 to 10 might be not necessary if other components have been already delivered in the same subsystem for the current release)

  1. Dev creates a CRT to advertise the release on the Tracking System. This is useful for other Developers that depends on the component to know that their components might need an update in the release. {name: <EPC-Name>, status: New, sprint: <Release-Sprint>, Assignee: <Dev>, Parent Task: <SRT>}. The status of the CRT is New at this time and the ECC is not yet available. The Release Tickets is update to include the component type. In particular, the Enabling field has been removed and it has been replaced by the "Type" field (as shows in the following figure) with the following choices: Grouping, Enabling, Common Apps, Community Apps. When a release ticket is created, a value must be selected accordingly with the component type.
    Type Grouping


  2. If SRT does not exists when CRT is created (i.e. first component released in the Subsystem), Dev also creates the SRT: {name: <ESC-Name>, status: New, sprint: <Release-Sprint>, Assignee: <SMan>, Parent Task: <PRT>}.
  3. When the Dev has created the ECC and he/she has verified that it's complete and build successfully, Dev updates the CRT: {status: New -> Available, Watcher: <SMan>}. Please note that Dev adds the SMan as a watcher of the CRT; in this way SMan is notified that the ECC is ready to be attached to the ESC.
  4. SMan creates the ESC and attaches the ECC to the ESC.
  5. SMan updates the CRT: {status: Available -> Under Integration}.
  6. SMan updates the SRT: {status: New -> Available, Watchers: <RMan>}. Please note that SMan adds the RMan as a watcher of the SRT; in this way RMan is notified that the ESC is ready to be attached to the EPC.
  7. RMan attaches the ESC to the EPC.
  8. RMan enables on BTRT the Candidate Builds for the gCube release.
  9. RMan updates the SRT: {status: Available -> Under Integration}.
  10. RMan activate the continuous integration of the EPC.
  11. RMan updates the PRT: {status: Under Integration}.


Example of CRT

Release Integration

Once the ECC of a component has been attached to the EPC, it will be part of the integration and testing activates to make sure the component integrates successfully with the gCube system and satisfies the gCube quality assurance policies. In this phase, the CRT will be used to report issues related to the component integration.

Release Manager and Tester are responsible to look at reports and logs of BTRT builds to identify issues. In case of building issues:

  1. the Release Manager updates the CRT: {status: Under Integration -> Build Issue, comment: <issue description>}. The comment should always include a link to a relevant log/report file.
  2. The Dev is notified of the issue and fixes it.
  3. Once the issue is solved, the Dev updates the CRT: {status: Build Issue -> Under Integration, comment: <solution description>}
  4. Release Manager verify that the issue has been solved

Same steps applies also for other deployment or functional issues. In these case different statuses will be used: DT Issue for deployment testing issues and FT Issue for functional testing issues.

While here it is assumed the Release Manager as the reporter of issues, also other actors involved in the release procedure (i.e. Dev, SMan, Tester) can report issues.

In case of complex issues and/or issues that involves multiple components, the reporter can choose to open a new ticket on the Tracking System instead of using the CRT.

Example of a CRT updates in case of a build issue (see the History section)

Before to close the Release and after that the Release Manager updates the CRT in "Under Integration", an additional steps is provided. The introduction of the splitting of the release, the developers can deploy the candidate release artefact immediately on pre-production and then test them. After that , the deploy and testing phase for the not enabling component can start, as reported in the following steps:

  1. the Infrastructure Manager :update the CRT {status: Under Integration -> RTD on Preprod}.It indicates that the component has been published on stagin nexus repository (by explicitly launching an ETICS build on the current release or because the night build succeeded, more details in STAGING NOTE).This is used to notify the portal manager or the preprod infrastructure manager to upgrade that component on preprod, in this case they MUST be added in advance as watcher of the component release ticket (more details in PROVISIONING NOTE). This status MUST not be used for subsystem release ticket or the master release ticket.
  2. Developer updates the CRT status : {status: RTD on Preprod -> Deployed on Preprod}. It indicates that the developer updated the component autonomously in the pre-production infrastructure .
  3. Deployer or Pre-Prod Infrastructure Manager updates the CRT {status: RTD on Preprod -> Deployed on Preprod}. It indicates that the component has been deployed on ALL nodes of preproduction and is up and running.
  4. Tester Manager, after all portlets are tested (all Software Tested Ticket are "Tested on Preprod":Functional Testing Procedure) updates the Release Ticket CRT {status: Deployed on Preprod -> Tested on Preprod} . The developer and/or the portal manager or the preprod infrastructure manager are confident that the component behave as expected and can be released as is.

STAGING NOTE

In the nexus configuration is added the build number on staging repository. Developers, Deployer and/or pre-prod Infrastructure Manager must download the component to deploy (both in dev and pre-prod infrastructure) , from Nexus repository, having the build number.

PROVISIONING NOTE

When any component needs to be deployed, an automatic procedure by using provisioning (ANSIBLE) MUST be created in advance. The first time this situation is verified, the developer MUST create a ticket for provisioning support. The ticket for provisioning MUST be related to the release ticket. The ticket can only be closed when (all the bullet must be verified):

  1. the provisioning script has completed (by the developer or by the entitled people);
  1. a documentation regarding the script has to be created. The infrastructure and provisioning documentation lives here: https://support.d4science.org/projects/aginfraplut/wiki
  1. the ticket has been updated indicating where the provisioning script is available and where is the documentation.

Only when the provisioning ticket is closed the RTD on Preprod status can be set.

Release Closure

When all components expected for a release have been delivered and all building, deployment and functional issues have been solved, the release can be considered closed and the components distributed.

In order to close the release, these preparatory steps must be performed:

  1. RMan sets the option "Include in searchers" of gCube Staging repository to false
  2. BTRT continuous build type is set to Release build. In this way, BTRT will publish the artifacts of the next build into the gCube Release Repository.


When all artifacts are published on the gCube Release Repository - i.e., after a 100% successful Release build - (a single build should be needed):

  1. RMan updates the Release Log
  2. RMan creates the Release Notes page (using XML Release notes)
  3. RMan disables the BTRT builds
  4. RMan open a ticket to generate release description to include in the distribution page
  5. RMan sets the option "Include in searchers" of gCube Staging repository to true
  6. RMan closes all release tickets (PRT, SRT, CRT) associated with closed release: {status: Tested on Preprod -> Released}. In case a component has been excluded from the release (e.g. unsolved integration issues, delays in the delivery) the CRT is udpdated with status Removed {status: Under Integration -> Removed}
  7. RMan creates a tag svn for the entire released code
Retrieved from "https://wiki.gcube-system.org/index.php?title=Major/Minor_Release_Cycle_procedure&oldid=28890"