Difference between revisions of "Major/Minor Release Cycle procedure"
(→Components Delivery) |
(→Components Integration) |
||
| Line 58: | Line 58: | ||
'''N.B.:''' these steps applies only to the first component released in the context of a Subsystem of a new gCube release. For following components, steps from 4 to 8 might be not necessary. | '''N.B.:''' these steps applies only to the first component released in the context of a Subsystem of a new gCube release. For following components, steps from 4 to 8 might be not necessary. | ||
| − | = | + | = Component 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. | ||
| + | |||
| + | 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 | ||
| + | |||
| + | 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 [[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. | ||
| + | |||
| + | 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. | ||
= Components Release = | = Components Release = | ||
= Release Closure = | = Release Closure = | ||
Revision as of 14:21, 5 October 2015
Contents
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.
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 |
Release Preparation
When a new release of gCube system is decided, several preparatory activities are request to configure the different tools to host the integration of the new release:
- 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}
Component Delivery
When a component must be released in a gCube release, it is required to trace all the release phase with a component release ticket (CRT) that contains the status and the history of the release of the component.
When the new version of the component is ready to be released:
- 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. - If SRT does not exists when CRT is created (i.e. first component released in the Subsystem), [Role_Developer|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 is sure 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 updates the SRT:
{status: Available -> Under Integration}. - RMan activate the continuous integration of the EPC.
- RMan updates the PRT:
{status: Under Integration}.
N.B.: these steps applies only to the first component released in the context of a Subsystem of a new gCube release. For following components, steps from 4 to 8 might be not necessary.
Component 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.
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.
