Release Beta Deployment Testing Plans

1. Release BetaDeployment Testing Plans • Pedro Andrade • pedro.andrade@cern.ch

2. Outline • Strategy • Deployment Test Tool • ETICS Usage • Infrastructure • Integration Builds • System Deployment Testing

3. Expected Time • Execution times: • Build whole DILIGENT project: approximately 4 hours • Duilb individual subsystems: 10 mins to 1 hour • Deploy test whole DILIGENT poject> approximatly 6 hours (services only!) • Fixing bugs requires some time: • Even using Savane to increase the bigs publication speed • Even with normal developer support

4. Strategy • Libraries: • automatically assigned the status “integrated” • Services • tested using the Deployment Test tool and applied on the Service Archives produced by the build activity • Portlets: • cannot be automatically deployed by the the DL Mgmt • should be cancelled ? • should be manually tested ? • deployment script has to be provided • by whom ?

5. Deployment Test Tool • Based on the Collective Layer functionalities • Using the DL Management client to: • automatically deploy the services to be tested • solve the services dependencies • REQ: undeployment of services • BUG: clients have a different input parameters order • Using the Package Repository client to: • store/get the integration services to be tested • REQ: method to get the Service Archives ID giving the service name • REQ: support the storage of different versions of the same archive • BUG: a local copy of the Service Profile is required by the PR client • ????: should the Service Archive be retrieved from ETICS build server

6. Deployment Test Tool • Is composed by: • Java app to be executed from ETICS • sets up the environment • deploys and starts the DHN • gets service ID from PR • asks DL Management to deploy the service • queries DL Management for the success of the deployment • asks DL Management to undeploy the service (missing) • DL Management and PR clients • Dependent libraries • The Service Profiles are not included in the deployment test tool since now they are available in the Service Archive.

7. ETICS Usage • ETICS usage will be simplified: • dependencies are now solved by the CL • no need to have service-specific testing information • Only one ETICS subsystem/component is needed to host the deployment test tool • Each Service Archive configuration: • sets a dependency over the deployment test tool • ! ! ! test tool will be checked out at each build • defines a test command • REQ: a subsystem configuration to group service archives is needed 7

8. Infrastructure • Use an independent infrastructure to avoid conflicts with the development and pre-prod infrastructures • Can be shared with testing activity: • only “startup” services are shared • each activity registers and uses its own DHNs • deployment testing doesn’t need a gLite infrastructure • But: • which components can be shared without problems ? • DIS-IC, DIS-Register, DIS-Broker • DL Management, Package Repository • which version should be installed ?

9. Integration Builds • Execution of subsystem and project integration builds • REQ: submission of builds from the web app available • REQ: daily project builds automatically executed • REQ: no overwrite of previous results • Build repository and deploy test repository • ????: can have only one repository ? • Time estimation for project level deployment testing: • Services: • project build and deploy test = 1 day • subsystem build and deploy test + bug fixing = 2 cycles in 1 day • major progresses = 1 week (with normal support from developers) • Portlets: ?? (for manual deployment) • Libraries: automatic

10. System Deployment Testing • Is system deployment testing needed ? • no major requirements identified • However, it can be useful to: • understand the limitations of the deployment of the whole system from scratch • produce a list of possible services incompatibilities • provide input for the BMM service deployment strategy • This costs significant effort !