Difference between revisions of "Deployment Testing"
From Gcube Wiki
(Created page with '__TOC__ == Description == The objective of the deployment testing activity within D4Science-II is to ensure that the gCube software: * can be automatically deployed (including …') |
|||
| Line 3: | Line 3: | ||
== Description == | == Description == | ||
| − | The objective of the deployment testing activity | + | The objective of the deployment testing activity is to ensure that the gCube software: |
* can be automatically deployed (including internal/external dependencies) | * can be automatically deployed (including internal/external dependencies) | ||
* once deployed, that it starts and is activated correctly | * once deployed, that it starts and is activated correctly | ||
| − | The deployment testing activity is an important task within the software development cycle of any project. In | + | The deployment testing activity is an important task within the software development cycle of any project. In gCube, this activity is even more important since the system is entirely based on Web Services technology and all its services are expected to be automatically deployed by the gCube Collective Layer services in any gCube Hosting Node (gHN). To allow such capability the gCube services must be compliant with a number of pre-established conditions. The verification of such conditions is therefore the core task of this deployment testing activity. |
The gCube software is composed by three types of components: services, libraries, and portlets. Due to their different nature, each type of components, will be dealt in a different way during the the deployment testing activity: | The gCube software is composed by three types of components: services, libraries, and portlets. Due to their different nature, each type of components, will be dealt in a different way during the the deployment testing activity: | ||
| Line 13: | Line 13: | ||
* Services implement the gCube core functionalities and usually rely on other services and/or libraries at run-time. Since their deployment has to take into consideration these dependencies, the deployment testing activity assumes high importance. The deployment testing activity is carried out by executing the deployment test tool on all gCube services. | * Services implement the gCube core functionalities and usually rely on other services and/or libraries at run-time. Since their deployment has to take into consideration these dependencies, the deployment testing activity assumes high importance. The deployment testing activity is carried out by executing the deployment test tool on all gCube services. | ||
* Libraries are usually simple JAR files. Since they don't introduce any deployment constraint they are not submitted to the deployment testing activity. | * Libraries are usually simple JAR files. Since they don't introduce any deployment constraint they are not submitted to the deployment testing activity. | ||
| − | * Portlets rely on | + | * Portlets rely on [http://www.liferay.com/ Liferay] portal to host them. Due to constraints in the communication between portlets, all portlets have to be deployed in the same machine. As a consequence,all portlets are grouped in one common bundle represented by one ETICS module. The deployment test of this bundle is done by checking-out the bundle from ETICS and manually testing its local installation. |
The deployment of a gCube-based infrastructure is a complex task where SAs cannot be deployed randomly. Instead the infrastructure is deployed progressively, in a custom order, by deploying groups of services (Enabling SAs, VO-level SAs, VRE-level SAs, Portlets SAs) and executing different post-deployment configuration steps. | The deployment of a gCube-based infrastructure is a complex task where SAs cannot be deployed randomly. Instead the infrastructure is deployed progressively, in a custom order, by deploying groups of services (Enabling SAs, VO-level SAs, VRE-level SAs, Portlets SAs) and executing different post-deployment configuration steps. | ||
| Line 39: | Line 39: | ||
The deployment testing activity foresees the involvement of the following roles: | The deployment testing activity foresees the involvement of the following roles: | ||
| − | * | + | * [[Role Tester|Testers]]: |
** responsible for the execution of the deployment tests and to submit deployment test bugs | ** responsible for the execution of the deployment tests and to submit deployment test bugs | ||
| − | * | + | * [[Role Developer|Developers]]: |
| − | + | ||
** responsible for fixing deployment test bugs | ** responsible for fixing deployment test bugs | ||
| − | |||
== Infrastructure == | == Infrastructure == | ||
| Line 55: | Line 53: | ||
* gCube VRE Modeler : to perform the VRE Deployment test | * gCube VRE Modeler : to perform the VRE Deployment test | ||
| − | A detailed description of the testing infrastructure can be found [[ | + | A detailed description of the testing infrastructure can be found [[Testing Infrastructure|here]] |
| − | + | ||
| − | + | ||
Revision as of 18:17, 15 January 2012
Contents
Description
The objective of the deployment testing activity is to ensure that the gCube software:
- can be automatically deployed (including internal/external dependencies)
- once deployed, that it starts and is activated correctly
The deployment testing activity is an important task within the software development cycle of any project. In gCube, this activity is even more important since the system is entirely based on Web Services technology and all its services are expected to be automatically deployed by the gCube Collective Layer services in any gCube Hosting Node (gHN). To allow such capability the gCube services must be compliant with a number of pre-established conditions. The verification of such conditions is therefore the core task of this deployment testing activity.
The gCube software is composed by three types of components: services, libraries, and portlets. Due to their different nature, each type of components, will be dealt in a different way during the the deployment testing activity:
- Services implement the gCube core functionalities and usually rely on other services and/or libraries at run-time. Since their deployment has to take into consideration these dependencies, the deployment testing activity assumes high importance. The deployment testing activity is carried out by executing the deployment test tool on all gCube services.
- Libraries are usually simple JAR files. Since they don't introduce any deployment constraint they are not submitted to the deployment testing activity.
- Portlets rely on Liferay portal to host them. Due to constraints in the communication between portlets, all portlets have to be deployed in the same machine. As a consequence,all portlets are grouped in one common bundle represented by one ETICS module. The deployment test of this bundle is done by checking-out the bundle from ETICS and manually testing its local installation.
The deployment of a gCube-based infrastructure is a complex task where SAs cannot be deployed randomly. Instead the infrastructure is deployed progressively, in a custom order, by deploying groups of services (Enabling SAs, VO-level SAs, VRE-level SAs, Portlets SAs) and executing different post-deployment configuration steps. As a consequence the deployment test activity has been organized in four main areas, to cover all aspects of deploying a gCube-based infrastructure.
- SA DT: To test the individual deployment of SAs. Verifies if SAs are correctly packaged and all declared dependencies are available;
- VRE DT: To test the deployment of VREs. Includes the deployment of all VRE-level services and the configuration of the VRE;
- VO DT: To test the deployment of one VO. Includes the deployment of all VO-level services and the configuration of the VO;
- Portal DT: To test the deployment of the infrastructure portal. Includes the deployment of the portal container and all user and administrator portlets.
The status of the deployment test activity can be summarized as follows:
- SAs and VREs DTs have been implemented and officially performed in the process of SA integration testing;
- The Portal DTs even if partially implemented, have not been completed and therefore officially used for portal integration testing. This decision has been taken due to changes in the underlying portlet technology, which is going move from the Gridsphere portal container to a not yet identified solution. The abandon of Gridsphere solution requires the Portal DTs to be rewritten from scratch;
- Finally, the VO DTs implementation has been postponed in order to wait for the ETICS multi-node testing functionality to be released in production.
Roles
The deployment testing activity foresees the involvement of the following roles:
- Testers:
- responsible for the execution of the deployment tests and to submit deployment test bugs
- Developers:
- responsible for fixing deployment test bugs
Infrastructure
The execution of deployment tests requires the pre-deployment of some gCube Collective Layer services:
- gCube Software Repository: to store and retrieve the services to test
- gCube VRE Management: to automatically deploy the services to test
- gCube Information Service: to query the status of the deployed services
- gCube VRE Modeler : to perform the VRE Deployment test
A detailed description of the testing infrastructure can be found here
