1. Garching, 08 July 2005 NRI (Night Reporting Infrastructure) for VLT Common Software Integration S. Feyrin, M. Zamparelli European Southern Observatory

2. Garching, 08 July 2005NRI for VLTSW2 Contents 1.NRI Generalities : NRI/dynamic: motivation and requirements NRI Layout 2.NRI for vltsw 3.Possible changes and extensions

3. Garching, 08 July 2005NRI for VLTSW3 NRI/dynamic: motivation 1.shorten the feedback loops from manual integration 2.bring to the attention of the developers software modules with missing or insufficient testing 3.bring to the attention of the developers software modules with suspect memory fingerprint 4.diminish the labor pain when migrating to new compiler version or OS release 5.have minimal trend analysis for various performance indicators

4. Garching, 08 July 2005NRI for VLTSW4 Requirements on NRI 1.Build environment should be the correct one 2.All applicable platforms should be exercised 3.Static and dynamic reports should correspond to the same version of the software 4.The build should take place from scratch 5.Tests should be executed in isolation (FIFO) 6.Ease of access to reports on the web for diagnosis 7.Tests running amock should not halt the integration

5. Garching, 08 July 2005NRI for VLTSW5 Configuration Management Static Inspection host 1 Database WebServer host 3 host 2 (dynamic inspection machines) Codewizard JTest sloccount cmt/cmtjava JDepend doxygen graphviz Purify/Valgrind splint JContract source reports NRI Layout

6. Garching, 08 July 2005NRI for VLTSW6 Machines HOSTPROJECTOSWHATTOOLS te64VLTSL3APPLIC.Purify SCI/OCI te53VLTSL4CSPurify OCI te26VLTHP-UX 11CSPurify OCI te44ALMARH9/rtaiAPPLIC. Purify SCI valgrind te31ALMARH9/rtaiCS Purify SCI valgrind te48ALMARH Ent. 4CSPurify SCI te58ALMASunOSCSPurify OCI te89ALMARH9/rtaiAPPLIC.Purify SCI

7. Garching, 08 July 2005NRI for VLTSW7 Integration Steps 1: normal build 2: normal test (TAT or otherwise based) 2,5: additional purify and test (if applicable) 3: purified build (vltMakefile based)vltMakefile 4: purified test (TAT or otherwise based)

8. Garching, 08 July 2005NRI for VLTSW8 PurifyPlus for Linux C/C++/JavaC/C++ SCIOCI Coverage Inspection Memory Inspection Good Bad Missing Available batch granularity

9. Garching, 08 July 2005NRI for VLTSW9 1.Dynamic ( build and test) Adapt NRI to work with non Makefile based approach of VLTSW Align results of automated integration and tests with the manual ones Solve problems related on LCU availability and usage Solve display related problems 2.Dynamic ( coverage and memory reports ) Run through PureCoverage and get consistent results!! Improve layout and readability of coverage reports Separate the weed from the crop in memory reports 3.Notification (responsibility assignment) 4.Static part

10. Garching, 08 July 2005NRI for VLTSW10 Links to the Web http://websqa.hq.eso.org/vlt/snapshot2/ http://websqa.hq.eso.org/vlt/snapshot3/vltsw- Reports/TestCoverage-Linuxhttp://websqa.hq.eso.org/vlt/snapshot3/vltsw- Reports/TestCoverage-Linux /

11. Garching, 08 July 2005NRI for VLTSW11 Purify CompiledTest DIR Makefile test target make test test output UNDETERMINED FAILEDPASSED UNDETERMINED TAT TAT signature Test result determination

12. Garching, 08 July 2005NRI for VLTSW12 Problems and Solutions (?) Execution time on HP-UX is prohibitive LAST or non LAST ? How frequently should it run ? Tools license availability ? pkingBuild should build a partition of the CMM modules space (http://websqa.hq.eso.org/vlt/PackagesAnalysis.html )http://websqa.hq.eso.org/vlt/PackagesAnalysis.html

13. Garching, 08 July 2005NRI for VLTSW13 NRI: dynamic + static Implementation of Integration steps on a “daily” basis Daily build report on appropriate OS from last code revision Coding Standards (actually industry best practices) reports (VLTSW20030379 VLTSW20030380)VLTSW20030379 VLTSW20030380 Naming conventions, dependency diagrams, subsystem partition in modules. McCabe Cyclomatic Complexity and Halstead Volume, in-line documentation sufficency in-line documentation Lines of code at subsystem and global level test lines of code at subsystem level Unit test coverage amount of check-in operations SPRs per subsystem

14. Garching, 08 July 2005NRI for VLTSW14 RESERVE SLIDES FOLLOW

15. Garching, 08 July 2005NRI for VLTSW15 Night Reporting Infrastructure Limitations: no check for C++ VxWorks LCU code yet (missing compiler for Linux) avoid false positives handling exceptions is difficult inspection is only possible for compilable (C++) or compiled (Java) code avoid collecting info on generated code, not always trivial Tcl/Tk missing and in general weak on scripting languages