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

Revision as of 14:07, 30 September 2015

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.

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

Acronyms List

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 Tracking system. They are also announced to all developers through mailinglists and social channels.

How to deliver a component

Release Cycle Steps

Preparing the Release Cycle (RMan)

This step is in charge to RMan who:

1. creates a new EPC for the upcoming gCube version. It should be cloned from the org.gcube.HEAD EPC
2. schedules automatic integration builds for the new EPC in BTRT
3. creates a new milestone on the gCube tracking system
4. notify by mailinglist SMans and Devs about the starting of the new release cycle and its deadline.

Delivering Components (Dev)

If a new version for a component is expected for the upcoming release (or if a Dev wants to release a new version of his component), the Dev has in charge the delivery of his component(s). Steps he must follows in order to delivery his component are:

1. if version to delivery has major and/or minor changes
   • create a release branch respecting all contemplated 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
2. create a new ECC (possibly by cloning) for his component. The ECC must:
   • respect all the 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
3. 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
4. communicate to 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.
5. 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 Dev must ask the SMan to remove the ECC from the ESC.

Delivering Subsystems (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 SMan to release a new ESC:

1. receives notification from Devs about new ECCs avaiability in the scope of his subsystem
2. creates a new ESC (by cloning the previous one)
3. substitutes old ECCs with new ones
4. 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
5. creates a release ticket announcing the ESC release (see below) 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. Tickets related to the ESC release must have the milestone field set to the release number in which the ESC is being released.
6. CREATE RELEASE TICKET
7. 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, SMan must create a release ticket on tracking system to press RMan to include new ESC in the EPC.

Release ticket is a ticket with these properties:

An example of creation of a valid release ticket follows.

Update EPC (RMan)

RMan receives release tickets and does following steps in order to integrate new ESC in the upcoming release:

1. receives release ticket from SMan
2. updates the EPC accordingly to release tickets
3. forward release ticket to the 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 (RMan)

Through this activity, EPC configuration is built until all modules are free from integration defects. Build activity is better explained in the section Build Activity. These are, briefly, main steps:

• EPC is automatically built twice a day (at 00:00 CET and 11:00 CET, see this 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 application as soon as build ends up

For each executed EPC build, RMan:

1. looks for integration defects (see below)
2. if integration defects are discovered, open integration defect tickets
3. with regard to integration defect tickets opened for the previous build, if defects are solved in the current build, close them
4. 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 (RMan, 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 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.

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, RMan open a integration defect ticket in the tracking system. The integration defect ticket (assigned to the component's Dev) should clearly indicate the defect (if RMan can guess it) and link all useful reports/logs in BTRT.

Resolving Integration Defects (RMan, Devs)

Resolving integration defects is in charge to 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, it is very important that Dev does not forget to update the SVN revision number in tag field of the ECC, making it pointing at latest source code version!

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 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 (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 TTeam when a Deployment Testing Session is carried out:

1. carry out deployment testing on artefacts in the latest EPC build
2. generate a dt_report and publish it to the DTRepository. That report will be downloaded and become accessible from within BTRT (see Fetch Server section for further details)
3. in case some defects are revealed during deployment tests execution, open new testing defect tickets
4. close testing defect tickets solved in the current deployment tests execution
5. 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

Reacting to Deployment Testing Defects (Devs)

When a defect is discovered in the deployment of a component during deployment testing, TTeam opens a testing defect ticket assigning it to component's Dev. Procedure to solve and close the defect is the same applied in Resolving Integration Defects.

Release Cycle closure

When the TTeam is satisfied with the software, the latter can be released to production. This, final, step is in charge to the RMan who:

• 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 (link)
• announce officially gCube version (indicating features) through d4science-ii news system