Difference between revisions of "Procedure QA Deployment"
Andrea.manzi (Talk | contribs) (→Preparation of the QA validation plan) |
Andrea.manzi (Talk | contribs) (→Understanding the packages to upgrade) |
||
| Line 47: | Line 47: | ||
x.y.z-i | x.y.z-i | ||
| − | x = major : if the x version of the component has changed compared to the previous release | + | 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 = minor : if the y version change, the component has been enhanced but the changes are all backward compatible | ||
Revision as of 17:00, 18 February 2014
Preparation of the QA validation plan
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 these 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
In addition the compos belonging to the following
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.
Those components represent the base
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.
