Revision as of 14:44, 22 October 2015

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 datails 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.

Acronyms List

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.
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}.

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.

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 sets the option "Include in searchers" of gCube Staging repository to true
5. RMan closes all release tickets (PRT, SRT, CRT) associated with closed release: {status: Under Integration -> 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}