Procedure QA Deployment

QA Deployment

One of the phase of the software lifecycle is the validation of the software in an environment production-like. This phase is also referred an pre-production or QA deployment and validation and it has been implemented as well in the case of gCube and its deployment on the D4ScienceAn e-Infrastructure operated by the D4Science.org initiative. infrastructure.

Given the limited resources and effort it was not possible to replicate an environment as the production one for the QA phase, therefore part of the resources exploited during this phase are shared with the production environment. In the case of gCube the list of the resources dedicated to QA are available on the wiki page. As described on the wiki 2 sites are contributing : NLKUA and CNR. This sharing with the production infrastructure is also reflected at the level of scope hierarchy: the QA environment is not a separated infrastructure as it happens for the development and the testing environment but it consists on a VOVirtual Organization; ( Ecosystem) under the production infrastructure scope. (/d4science.research-infrastructures/Ecosystem). One VREVirtual Research Environment. is also available (TryIt)in order to validate VREVirtual Research Environment. specific services.

Procedures

As already said the QA phase has limited resources allocated therefore is focus is mainly on a subset of the upgrade activities described at http://wiki.i-marine.eu/index.php/Procedure_Infrastructure_upgrade#Upgrade_Activities:

• testing the upgrade of the deployed containers using the scripts
• tested the deployment of new developed gCube services
• tested the deployment of the portal components

in addition this phase include some validation of the deployment components with the data present in production.

Components forming a gCube Release

A gCube release result of the integration activity implemented by WP7 could include a high number of new and upgrade components. The information about the components that are part of a release are listed in trac under the report ( grouped by milestone)

https://issue.imarine.research-infrastructures.eu/report/17

Each subsystem listed on the report includes different types of components to upgrade/install on the infrastructure. In order to understand what are the components to include and how to plan the upgrade we have a list of known categories.

Bundle components

Belongs to this group of components the base containers of our infrastructure components:

• org.gcube.portal.portal-bundle
• org.gcube.distribution.ghn-distribution
• org.gcube.distribution.smartgears-distribution

When a new version of these components is released we should check the impact in terms of libraries/configuration to upgrade and prepare upgrade scripts/detailed instructions.

Enabling Layer components

Belongs to this category the components that are the the enablers of our infrastructure, the base services that allows discovery, resource management, service deployments etc etc:

• org.gcube.vre-management
• org.gcube.information-system
• org.gcube.vo-management
• org.gcube.messaging
• org.gcore

Portal components

Components GUI side to to be installed only on the infrastructure portal:

• org.portlets-*
• org.portal-
• org.gcube.application-support-layer.*

In addiction to these subsystem, some other GUI side components are part of the subsystems. org.gcube.application and org.gcube.messaging.

Understanding the packages to upgrade

In Etics we have defined different numbering for each component released:

x.y.z-i

x = major : if the x version of the component has changed compared to the previous release, therefore his public Interface has changed, so its upgrade depends on the availability of the other components to adapt to it

y = minor : if the y version change, the component has been enhanced but the changes are all backward compatible

y = patch : if the z version change, the components includes a fix only

i = build : we use this version change only to track changes at the level of packaging/etics. The components has not changes at the level of code or configuration so no upgrade should be performed.