Deployment Testing

From Gcube Wiki
Jump to: navigation, search


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.

While SA DT are automatically done during the integration builds by ETICS, the other type of deployment tests are manually performed when deploying services in the pre-production infrastructure.


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


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