Major/Minor Release Cycle procedure
Contents
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:
- 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:
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:
- 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.
The following figure shows the Release Gant for the new procedure:
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”
- X → “Under Integration” status change in release tickets. E.g.:
- 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:
- RMan creates a Sprint on the Tracking System for the release (e.g. "Release gCube 3.9.0")
- RMan creates the PRT
{name: <EPC-Name>, status: New, sprint: <Release-Sprint>} - RMan creates the EPC cloning it from org.gcube.HEAD
- 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)
- 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
- 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>}. - 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. - SMan creates the ESC and attaches the ECC to the ESC.
- SMan updates the CRT:
{status: Available -> Under Integration}. - 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. - RMan attaches the ESC to the EPC.
- RMan enables on BTRT the Candidate Builds for the gCube release.
- RMan updates the SRT:
{status: Available -> Under Integration}. - RMan activate the continuous integration of the EPC.
- RMan updates the PRT:
{status: Under Integration}.
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:
- 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. - The Dev is notified of the issue and fixes it.
- Once the issue is solved, the Dev updates the CRT:
{status: Build Issue -> Under Integration, comment: <solution description>} - 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.
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
{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. - 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 . - 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. - 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):
- the provisioning script has completed (by the developer or by the entitled people);
- 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.
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:
- RMan sets the option "Include in searchers" of gCube Staging repository to false
- 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):
- RMan updates the Release Log
- RMan creates the Release Notes page (using XML Release notes)
- RMan disables the BTRT builds
- RMan open a ticket to generate release description to include in the distribution page
- RMan sets the option "Include in searchers" of gCube Staging repository to true
- 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} - RMan creates a tag svn for the entire released code
