Speakers
Description of the Work
During EMI Project first year, the central EMI Testing Infrastructure setup work focused on implementating two separated testbeds: the inter-component testing infrastructure and the large scale acceptance testing infrastructure.
The inter-component testing infrastructure is meant to be the first central point of contact among different EMI products, i.e. the place where each product functionalities and expected behavior are tested against other related EMI products. This is implemented by permanently deploying instances of both production and release candidate versions of all products components for every EMI release. Hence an evolving snapshot of all released and upcoming versions of all EMI products is provided to product team developers. Configurable central information system instances publishing resources in the testbed assure flexible and dynamic creation of testbed subset views.
This initial inter-component testbed model, implemented and exploited for EMI-1 Release, has recently evolved to better face requirements emerged from certification usage experience. In particular the integration testbed has been divided in two distinct subsets: i) a snapshot of EMI production version releases used to test the backward compatibility of components and for final verification of up-coming release updates ; ii) a snapshot of EMI release candidate version releases aligned with testing repositories and automatically updated to implement the continuous integration infrastructure. In fact contiuous integration imply continuous alignment of testbed to the latest available product build. Moreover the both infrastructures have been exposed to automatic testing probes monitoring tool (e.g. SAM-NAGIOS).
Also the large scale acceptance testing infrastructure model has evolved. The objective here is to maximize the exposition of considered product to production-like environment usage in terms of geographical distribution or different deployment scenarios or scale. The initial de
Overview (For the conference guide)
EMI Project has succeded in merging into a single release (EMI 1 Kebnekaise) more than fifty software products from four major European technology providers (ARC, gLite, UNICORE and dCache). To satisfy end user expectation in terms of functionality and performance, release process implements several steps of certification and verification. The final phases of certification are aimed at harmonizing the strongly inter-dependent products coming from various development teams through parallel certification paths. The role of EMI Testing Infrastructure is to provide operational and infrastructural resources to implement intercomponent certification phases and involve EMI end user in early testing or preview activity.
The presentation will describe the EMI testing infrastructure and the lesson learned after EMI-1/2 release experience.
Impact
The work presents operational and infrastructural solutions put in place to setup EMI Testing Infrastructure. Moving from a brief introduction to challenges faced during first EMI project year, the presentation will focus on advancements in the infrastructure implementation modalities aimed at maximizing both EMI product exposure to automatic testing tools and EMI products user communities.
Conclusions
The main outcome of the work was the improvement of EMI centralized testing infrastructure and operational resources in order to better support both continuous integration and release quality verification steps. The increased number of testbed users and contributors as well as the differentiation of activities involving external EMI product users community witnesses a better fullfilment of EMI testing infrastructure mission, e.g. exposing EMI products to the highest possible number of usage modalities.
