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

From Gcube Wiki
Jump to: navigation, search
(→‎Introduction)
(→‎Release Integration)
 
(55 intermediate revisions by 2 users not shown)
Line 28: Line 28:
 
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.  
 
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.  
  
−
<pre style="color:blue"> -NEW-
+
The new procedure has been thought to change the current practices and improve the exploitation of the resources:
−
An update about the Release Cycle procedure is introduced in order to reduce the current lack of  
+
 
−
a stable environment for the development
+
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
−
of the gCube "application" that relies on libraries and services of the "enabling layer".
+
 
 +
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.  
 +
 
  
−
For example GeoAnalytics (application) relies on SmartGears (enabling layer) or portlets (application) relies on portal.
+
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.
  
−
At the moment the editor writing, the release is the same for the enabling layer and application.
+
The following figure shows the Release Gant for the new procedure:
−
But the enabling component could change the day before closing the current release forcing
+
[[File:ReleaseGant.jpg|center|frame|ReleaseGant Release Cycle]]
−
all components that rely on it to change accordingly.
+
−
 
+
−
For these reason, the developers of the application, sometimes didn't have enough time and a stable environment
+
−
to finalize the development/testing of their components before the expected closure of the release.
+
−
The followig improvements are adopted in the Release Cycle procedure:
+
−
* to add a new field is added to the Release Ticket to identify the component is an "enabling" or not.
+
−
This field will allow to gCube users to build reports and have an overview of the release status.
+
−
* The release cycle will be open earlier (ideally just after the closure of the previous one) allowing
+
−
all components to be released as soon as they are ready.
+
−
A component should be released as soon as one feature is ready and can be updated multiple times during the release cycle.
+
−
For example: 3 new features are expected for component X. As soon as feature 1 is ready,
+
−
X is released. When release 2 is ready, X is updated (rev. num. increased) and so on.
+
−
This allow to add in the release the new features asap, maximizing the time that apps developers have
+
−
to integrate those features in their components.
+
−
* The release of new features in the enabling components will be allowed until a given deadline in the release cycle.
+
−
After this deadline, enabling will be "frozen" (unless bug fixing), while all other components
+
−
will be still allowed to be released.
+
−
This will give the apps developers enough time to integrate the new enabling features and release their components.
+
−
A new field is added in order to identify which gCube components are considered Enabling or Not.
+
−
The Developer or Subsystem Manager updates this field.
+
−
An example is reported below:
+
−
</pre>
+
−
[[File:Enabling.jpg|center|frame|Example of the Enabling Field]]
+
  
 +
<br>
 +
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.
 +
<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.
 
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>
 
<br>
  
 
= Release Preparation =
 
= Release Preparation =
 +
 
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:
 
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:
 
# [[Role_Release_Manager|RMan]] creates a ''Sprint'' on the [[Redmine|Tracking System]] for the release (e.g. "Release gCube 3.9.0")
 
# [[Role_Release_Manager|RMan]] creates a ''Sprint'' on the [[Redmine|Tracking System]] for the release (e.g. "Release gCube 3.9.0")
Line 75: Line 86:
  
 
(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)
 
(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)
−
# [[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.
+
<br>
−
<pre style="color:blue">NEW - The Developer updates the Enabling field too as reported in the [[#Introduction]] session.</pre>
+
<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.
  
−
# 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>.
+
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.  
−
# 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.
+
−
# [[Role Subsystem Manager|SMan]] creates the ESC and attaches the ECC to the ESC.
+
−
# [[Role Subsystem Manager|SMan]] updates the CRT: <code>{status: Available -> Under Integration}</code>.
+
−
# [[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.
+
−
# [[Role Release Manager|RMan]] attaches the ESC to the EPC.
+
−
# [[Role Release Manager|RMan]] enables on BTRT the ''Candidate Builds'' for the gCube release.
+
−
# [[Role Release Manager|RMan]] updates the SRT:  <code>{status: Available -> Under Integration}</code>.
+
−
# [[Role Release Manager|RMan]] activate the continuous integration of the EPC.
+
−
# [[Role Release Manager|RMan]] updates the PRT:  <code>{status: Under Integration}</code>.
+
  
 +
[[File:TypeField.jpg|center|frame|Type Grouping]]
 +
 +
 +
</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>
  
 
[[File:Release ticket.png|center|frame|Example of CRT]]
 
[[File:Release ticket.png|center|frame|Example of CRT]]
Line 109: Line 138:
 
[[File:Build_issue_ticket.png|center|frame|Example of a CRT updates in case of a build issue (see the History section)]]
 
[[File:Build_issue_ticket.png|center|frame|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" , start the deploy and testing phase as reported in the following steps:
+
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:
  
 
# 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.
 
# 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 .
 
# 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.
 
# 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 updates the 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.
+
#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.
  
−
<pre>STAGING NOTE
+
== STAGING NOTE ==
  
 
In the nexus configuration is added the build number on staging repository.  
 
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  
 
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.
 
(both in dev and pre-prod infrastructure) , from Nexus repository, having the build number.
−
</pre>
 
  
−
<pre>PROVISIONING NOTE
+
== PROVISIONING NOTE ==
  
−
When the deployment of a component involve more than two nodes, an automatic procedure  
+
When any component needs to be deployed, an automatic procedure  
−
by using provisioning (ANSIBLE) MUST be created in advance.  
+
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 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  
+
The ticket for provisioning '''MUST''' be related to the release ticket. The ticket can only be closed when  
 
(all the bullet must be verified):
 
(all the bullet must be verified):
  
−
* the provisioning script has completed (by the developer or by the entitled people);
+
# the provisioning script has completed (by the developer or by the entitled people);
  
−
* a documentation regarding the script has to be created;
+
# a documentation regarding the script has to be created. The infrastructure and provisioning documentation lives here: https://support.d4science.org/projects/aginfraplut/wiki
  
−
* the ticket has been updated indicating where the provisioning script is available and where is the documentation.
+
# 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.
 
Only when the provisioning ticket is closed the RTD on Preprod status can be set.
−
</pre>
 
  
 
= Release Closure =
 
= Release Closure =
Line 154: Line 181:
 
# [[Role_Release_Manager|RMan]] open a ticket to generate release description to include in the distribution page
 
# [[Role_Release_Manager|RMan]] open a ticket to generate release description to include in the distribution page
 
# [[Role_Release_Manager|RMan]] sets the option "Include in searchers" of gCube Staging repository to ''true''
 
# [[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: Under Integration -> 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]] 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
 
# [[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"