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

From Gcube Wiki
Jump to: navigation, search
(→‎Release Integration)
(→‎Introduction)
Line 57: Line 57:
 
* A new field is added to the Release Ticket to identify the component is an "enabling" or not.
 
* A new field is added to the Release Ticket to identify the component is an "enabling" or not.
  
−
<pre>
 
−
It is important to remember the background to understand the introduction of the new release procedure:
 
  
−
As reported in the https://wiki.gcube-system.org/gcube/GCube_Reference_Architecture ,
 
−
two type of services are considered :
 
−
* gCube Infrastructure Enabling Services and
 
−
* gCube Application Services.
 
−
 
−
The gCube Infrastructure Enabling Services  provides all component (we calls enabling component)
 
−
needed to the correct work of the Infrastructure as SmartGear or Portal .
 
−
 
−
The gCube Application Services can be considered other type of components relying on enabling layer :
 
−
for example,  the application GeoAnalytics relies on SmartGear (it's an enabling layer),
 
−
or the application portlets relies on Portal enabling components.
 
−
 
−
The problem, for the developer, is that during the release the enabling component could change
 
−
the day before the closure (the current release) forcing all component that rely on it to change accordingly:
 
−
actually, the release is the same for the enabling and application components.
 
−
 
−
Consequently, 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 from the release.
 
−
In order to reduce the lack from the enabling layer and the application components some improvements
 
−
are adopted in the Release Cycle procedure. In particular , the release will be divide
 
−
in two release one for the enabling and one for the application services.
 
−
</pre>
 
 
<br>
 
<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.

Revision as of 16:10, 3 March 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.

-NEW-


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.

This new procedure tries to deliver candidate stable version of the enabling components to application developers and to offer a stable pre-production infrastructure for its exploitation.

The following recommendations are provided:

  • 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 applications 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 applications developers enough time to integrate the new enabling features and release their components.

  • The subsystems are not enabling : their components can be enablin or not.
  • The pre-production infrastructure becomes an environment continuously available and not limited to the functional test activities that are performed in the last weeks before the deployment in production.
  • A new field is added to the Release Ticket to identify the component is an "enabling" or not.



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.

The intermediary deadlines (before the roll-out) are introducted. They involve the deadline:

  • to freeze the enabling components;
  • to upgrade the pre-production environment;
  • for the FT enabling;
  • to freeze the "not" enabling components;
  • to upgrade the pre-production with "not" enabling components;
  • for the FT of the "not" enabling components;
  • roll-out.

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.

    NEW

    The Developer updates the Enabling field too.

    This field will allow to gCube users to build reports and have an overview of the release status.


    Example of the Enabling Field
  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

The flow for the Tracker Releases is:

New > Available > Under Integration > Build Issue (it goes back to under integration) OR RTD on Preprod > Deployed on Preprod or DT Issue (it goes back to Deployed On Preprod) > Released The flow is showed in the following figure:

CRTWorkflow.png

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" ,

NEW

an additional steps is provided. Infact, with the split of the release the developers can deploy 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.
UPDATED
  1. 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=28482"