|
|
| Line 1: |
Line 1: |
| | = Introduction = | | = Introduction = |
| − | This section describes the Release Cycle procedure focusing on activities to be executed and roles involved. The figure below shows the activities in the procedure. Each activity involves only one role and provide the input for the next activity. | + | 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]]. |
| | | | |
| | [[Image:Release_cycle.png|center]] | | [[Image:Release_cycle.png|center]] |
| | | | |
| − | In the description of steps below, knowledge of the ETICS datamodel (e.g. the concepts of project, subsystems, components, configurations) is assumed.
| |
| − |
| |
| − | As a rough definition, we can say that a '''project''' is composed of '''subsystems''', which is further organized in '''components'''. These are generically termed '''modules'''. A specific version of a module is called '''configuration'''. Further details about ETICS can be found in the [[ETICS|ETICS]] section.
| |
| | | | |
| | == Acronyms List == | | == Acronyms List == |
| Line 33: |
Line 30: |
| | |} | | |} |
| | | | |
| − | == Start of a Release Cycle ==
| |
| − |
| |
| − | Release Cycles aim to release a new version of gCube software '''providing a set of new functionalities'''. Release Cycle can start only when all expected functionalities targeted for the release are available in the trunk branch of the gCube SCM Repository. Deadlines to start a cycle, deliver components, integrate and test candidate configurations and close the cycle are made available as Milestone in the [[Redmine|Tracking system]]. They are also announced to all developers through mailinglists and social channels.
| |
| − |
| |
| − | == How to deliver a component ==
| |
| − | [[File:Components_release.png|800px]]
| |
| − |
| |
| − | == Release Cycle Steps ==
| |
| − |
| |
| − | === Preparing the Release Cycle ([[Role Release Manager|RMan]]) ===
| |
| − | This step is in charge to [[Role Release Manager|RMan]] who:
| |
| − | # '''creates a new EPC''' for the upcoming gCube version. It should be cloned from the org.gcube.HEAD EPC
| |
| − | # schedules '''automatic integration builds''' for the new EPC in BTRT
| |
| − | # creates a '''new milestone''' on the [[Redmine | gCube tracking system]]
| |
| − | # '''notify by mailinglist''' [[Role Subsystem Manager|SMans]] and [[Role Developer|Devs]] about the starting of the new release cycle and its deadline.
| |
| − |
| |
| − | === Delivering Components ([[Role Developer|Dev]]) ===
| |
| − | If a new version for a component is expected for the upcoming release (or if a [[Role Developer|Dev]] wants to release a new version of his component), the [[Role Developer|Dev]] has in charge the delivery of his component(s). Steps he must follows in order to delivery his component are:
| |
| − |
| |
| − | # if version to delivery has major and/or minor changes
| |
| − | #*'''create a release branch''' respecting all contemplated [[Gcube subversion repository|conventions]]
| |
| − | #** developers should insert a meaningful comment (list of changes/features) when execute branching operation in order to make possible automatic generation of Release-Log files
| |
| − | #* otherwise (in case of delivery of a patch version) no release branch has to be created and the proper release branch must be used
| |
| − | #'''create a new ECC''' (possibly by cloning) for his component. The ECC must:
| |
| − | #* respect all the [[Naming Conventions|Naming Conventions]]
| |
| − | #* '''''tag'' property must point to the proper release branch in SVN repository''' (e.g. branches/ext/hibernate-servicearchive/3.2@19387)
| |
| − | #* advertise changes though a proper increase of the version number
| |
| − | # '''build remotely''' (at least one time) the ECC in the context of the newly created EPC in which it will be included
| |
| − | #* if build is successful then go to step 4
| |
| − | #* else resolve problems, update the ECC and go back to step 2
| |
| − | # <del>'''communicate to [[Role Subsystem Manager|SMan]]''' (no means established for this notification) that ECC is ready to be included in subsystem configuration. This communication has to report the activities that led to the new ECC in terms of the tickets (bugs, features) number. Those tickets are expected to be associated with the 'Ready To Release' Release Status field.</del>
| |
| − | # '''OPEN Release Ticket with the name of component'''
| |
| − |
| |
| − |
| |
| − | Please note that these step are needed only if a new version of the component has to be released. Otherwise the ECC used for the Release Cycle will be the same included in the latest gCube version.
| |
| − |
| |
| − | If the component is discontinued, the [[Role Developer|Dev]] must ask the [[Role Subsystem Manager|SMan]] to remove the ECC from the ESC.
| |
| − |
| |
| − | === Delivering Subsystems ([[Role Subsystem Manager|SMan]]) ===
| |
| − | In gCube data model, Subsystems are aggregation of modules. If new ECCs are created for one or more modules in a subsystem, then parent Subsystems have to be released too.
| |
| − |
| |
| − | These are the steps in charge to [[Role Subsystem Manager|SMan]] to release a new ESC:
| |
| − | # '''receives notification from Devs''' about new ECCs avaiability in the scope of his subsystem
| |
| − | # '''creates a new ESC''' (by cloning the previous one)
| |
| − | # substitutes old ECCs with new ones
| |
| − | # '''builds new ESC remotely''' (on ETICS infrastructure) in the context of the newly created EPC
| |
| − | #* if the build is successful then go to step 5
| |
| − | #* else notify Devs, who will update their ECCs, and go back to step 3
| |
| − | # <del>'''creates a release ticket''' announcing the ESC release (see below) <strike>by reporting also the tickets number describing the activities performed to achieve the ECCs belonging to the ESC. The ticket numbers have to be reported in the Blocking field of the release ticket.</strike> Tickets related to the ESC release must have the milestone field set to the release number in which the ESC is being released.</del>
| |
| − | # '''CREATE RELEASE TICKET'''
| |
| − | # ATTACH SUBSYSTEM RELEASE TICKET TO SYSTEM RELEASE TICKET (e.g Release 3.9.0).
| |
| − |
| |
| − |
| |
| − | Please note that these step are needed only if a new version of a subsystem has to be released. If no new ESC is planned for the upcoming gCube version (e.g. no new ECCs in the subsystem), no actions are needed (the ESC used for the release cycle will be the same included in the latest gCube version).
| |
| − |
| |
| − | ==== Creating a release ticket ====
| |
| − |
| |
| − |
| |
| − | When a new ESC is available, [[Role Subsystem Manager|SMan]] must create a ''release ticket'' on [[Redmine|tracking system]] to press [[Role Release Manager|RMan]] to include new ESC in the EPC.
| |
| − |
| |
| − | ''Release ticket'' is a ticket with these properties:
| |
| − | {| border="0" cellpadding="4" cellspacing="0"
| |
| − | |-
| |
| − | |-
| |
| − | | '''summary''' || "[ESC-name] available for release"
| |
| − | |-
| |
| − | | '''description''' || ''free text. <u>Must include at least the list of new (and only new) ECCs</u>''
| |
| − | |-
| |
| − | | '''type''' || "release"
| |
| − | |-
| |
| − | | '''Milestone''' || [EPC-name]
| |
| − | |-
| |
| − | | '''Status''' || "available"
| |
| − | |-
| |
| − | | '''Subsystem''' || [Subsystem-name]
| |
| − | |-
| |
| − | | '''Subsystem Configuration''' || [ESC-name]
| |
| − | |-
| |
| − | | '''Assign to''' || ''[[Role Release Manager|RMan]]''
| |
| − | |-
| |
| − | | <strike>'''Blocking'''</strike> || <strike>''comma-separated list of blocking tickets (see above)'' (e.g. "123, 437, 765")</strike> Not required anymore
| |
| − | |}
| |
| − |
| |
| − |
| |
| − | An example of creation of a '''valid release ticket''' follows.
| |
| − |
| |
| − | [[Image:Release-ticket.png|center|frame]]
| |
| − |
| |
| − | === Update EPC ([[Role Release Manager|RMan]]) ===
| |
| − | [[Role Release Manager|RMan]] receives ''release tickets'' and does following steps in order to integrate new ESC in the upcoming release:
| |
| − | # '''receives''' ''release ticket'' from SMan
| |
| − | # '''updates the EPC''' accordingly to ''release tickets''
| |
| − | # forward release ticket to the [[Role Release Manager|RMan]] changing the status: '''Available --> Ready to Build'''
| |
| − |
| |
| − | From this moment on, the ESC (and its components) will be built among other components during EPC builds (see below).
| |
| − |
| |
| − |
| |
| − | Release ticket without software validation report or not satisfactory software validation reports are rejected and the ESC is not added to the EPC.
| |
| − |
| |
| − | === Building ([[Role Release Manager|RMan]]) ===
| |
| − |
| |
| − | Through this activity, EPC configuration is built until all modules are free from ''integration defects''. Build activity is better explained in the section [[Continuous Integration procedure#Build Activity|Build Activity]]. These are, briefly, main steps:
| |
| − |
| |
| − | * '''EPC is automatically built twice a day''' (at 00:00 CET and 11:00 CET, see this [[Continuous Integration procedure#Time Table|Time Table]] for details) using the Building Infrastructure
| |
| − | * during the build process a number of reports are generated in order to check components' compliance with settled guidelines and requirements (e.g. findbugs and checkstyle plugins, sa-certification, checking of component versions correspondence)
| |
| − | * reports and logs become available on [[BTRT|BTRT]] application as soon as build ends up
| |
| − |
| |
| − |
| |
| − | For each executed EPC build, [[Role Release Manager|RMan]]:
| |
| − | # looks for integration defects (see below)
| |
| − | # if integration defects are discovered, open ''integration defect tickets''
| |
| − | # with regard to ''integration defect tickets'' opened for the previous build, if defects are solved in the current build, close them
| |
| − | # if the build is successful change status of ''release tickets'' (if not yet done) from '''Ready to Build''' --> '''Ready to DT''' (this will trigger Deployment Testing activity)
| |
| − |
| |
| − | Build activity last until all components are free from integration defects. Next sub-sections will explains how to find integration defects and how to react to them.
| |
| − |
| |
| − | ==== Discovering Integration Defects ([[Role Release Manager|RMan]], [[Role Developer|Dev]]) ====
| |
| − | If a module do not build successfully in the context of EPC builds, most likely it has integration defects (assuming it builds in isolation in the development environment; otherwise it should not be released at all). ''Integration defects'' are related commonly to errors/oversights in:
| |
| − | * dependencies definition
| |
| − | * naming
| |
| − | * checkout/build commands
| |
| − | * environment definition
| |
| − | * for ServiceArchives, profile.xml definition (will raise certification defects)
| |
| − |
| |
| − | The first place to discover integration defect is '''[[BTRT|BTRT]]'''. BTRT was designed and implemented exactly to make it easier to discover ''integration defects'' and their cause, providing a graphic interface that helps to quickly identify components with integration defects and a number of reports and logs to find their cause.
| |
| − |
| |
| − | [[Role Developer|Devs]] should, as frequently as they can, look at latest builds in BTRT in order to identify integration defects in their components and fix them.
| |
| − |
| |
| − | In case there is a "persistent" integration defect, [[Role Release Manager|RMan]] open a ''integration defect ticket'' in the [https://support.gcube-system.org/ tracking] system. The ''integration defect ticket'' (assigned to the component's Dev) should clearly indicate the defect (if [[Role Release Manager|RMan]] can guess it) and link all useful reports/logs in BTRT.
| |
| − |
| |
| − | ==== Resolving Integration Defects ([[Role Release Manager|RMan]], [[Role Developer|Devs]]) ====
| |
| − |
| |
| − | Resolving integration defects is in charge to [[Role Developer|Devs]]. Fix the defect usually involve changes in ECC configuration (e.g. fix a misspelled ETICS dependency). In some complex cases, to fix the defect changes in component's source code are required. In the latter case, <u>it is very important that [[Role Developer|Dev]] does not forget to update the SVN revision number in ''tag'' field of the ECC, making it pointing at latest source code version!</u>
| |
| − |
| |
| − | Once ECC has been updated, next EPC build is awaited (or, in case time for releasing is running out, an EPC build can be launched manually by [[Role Release Manager|RMan]]). If ECC build successfully in the new EPC build then the "integration defect ticket" is closed.
| |
| − |
| |
| − | It can be argued that this procedure could not work if the defect is notified when development has already progressed. However, the procedure is compatible with this situation as it relies on the assumption that Trunk/HEAD should not contain destabilizing changes that doesn't allow to fix and release.
| |
| − |
| |
| − | === Deployment Testing ([[Role Tester|TTeam]]) ===
| |
| − | Deployment Tests are carried out on artefacts produced by Build Activity. This activity is triggered from status change in ''release tickets''.
| |
| − |
| |
| − | These are steps in charge to [[Role Tester|TTeam]] when a Deployment Testing Session is carried out:
| |
| − | # carry out deployment testing on artefacts in the latest EPC build
| |
| − | # generate a dt_report and publish it to the DTRepository. That report will be downloaded and become accessible from within BTRT (see [[Building Infrastructure#Fetch_Server|Fetch Server]] section for further details)
| |
| − | # in case some defects are revealed during deployment tests execution, open new ''testing defect tickets''
| |
| − | # close ''testing defect tickets'' solved in the current deployment tests execution
| |
| − | # if Deployment Testing Session is successful, change status of release tickets (if not yet done) from Ready to DT --> Ready to FT (this will trigger Functional Testing activity)
| |
| − |
| |
| − | Typically, for each build a Deployment Testing session is carried out on build artefacts. A more detailed description of Deployment Testing activity can be found in the section [[Deployment Testing |Deployment Testing]]
| |
| − |
| |
| − | ==== Reacting to Deployment Testing Defects ([[Role Developer|Devs]]) ====
| |
| − | When a defect is discovered in the deployment of a component during deployment testing, [[Role Tester|TTeam]] opens a ''testing defect ticket'' assigning it to component's Dev. Procedure to solve and close the defect is the same applied in [[Major/Minor Release Cycle procedure#Resolving Integration Defects (RMan, Devs)|Resolving Integration Defects]].
| |
| | | | |
| − | <!-- Commented waiting new procedures
| + | = Release Preparation = |
| − | === Functional Testing ([[Role Tester|TTeam]]) ===
| + | 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: |
| − | Functional Tests are carried out on artefacts produced by Build Activity. This activity is triggered from status change in ''release tickets''. Functional Tests are executed against software deployed in [[Testing Infrastructure|Testing Infrastructure]]. Software is installed in Testing Infrastructure during Deployment Testing sessions.
| + | * RMan creates a milestone on the [[Redmine|Tracking System]] |
| | + | * |
| | | | |
| − | These are steps in charge to [[Role Tester|TTeam]] when a Functional Testing Session is carried out:
| + | = Components Delivery = |
| − | # carry out functional testing on software deployed in testing infrastructure
| + | |
| − | # generate a ft_report and publish it to the FTRepository. That report will be downloaded and become accessible from within BTRT (see [[Building Infrastructure#Fetch_Server|Fetch Server]] section for further details)
| + | |
| − | # in case some defects are revealed during functional tests execution, open new ''testing defect tickets''
| + | |
| − | # close ''testing defect tickets'' solved in the current functional tests execution
| + | |
| − | # if Functional Testing Session is successful, change status of release tickets (if not yet done) from Ready to FT - -> Ready to Release
| + | |
| | | | |
| − | A more detailed description of Functional Testing activity can be found in the section [[Functional Testing|Functional Testing]]
| + | = Components Integration = |
| − | -->
| + | |
| − | <!-- Commented waiting new procedures
| + | |
| − | ==== Reacting to Functional Testing Defects ([[Role Developer|Devs]]) ==== | + | |
| − | When a defect is discovered in component during functionality testing, [[Role Tester|TTeam]] opens a ''testing defect ticket'' assigning it to component's Dev. In the ticket a link to any useful report generated during testing session should be provided. Procedure to solve and close the defect is the same applied in [[Major/Minor Release Cycle procedure#Resolving Integration Defects (RMan, Devs)|Resolving Integration Defects]].
| + | |
| − | -->
| + | |
| | | | |
| − | === Release Cycle closure === | + | = Components Release = |
| | | | |
| − | When the [[Role Tester|TTeam]] is satisfied with the software, the latter can be released to production. This, final, step is in charge to the [[Role Release Manager|RMan]] who:
| + | = Release Closure = |
| − | * locks the EPC as it was at the time of latest build
| + | |
| − | * create a branch in SVN repository making a snapshot of released software for future maintenance release
| + | |
| − | * close all release tickets [status: released, resolved as: fixed]
| + | |
| − | * update relase log page ([[ CHECK IT|link]])
| + | |
| − | * announce officially gCube version (indicating features) through d4science-ii news system
| + | |
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.
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:
