Improving Software Quality with the Continuous Integration Server Hudson Dr. Ullrich Hafner Avaloq Evolution AG 8911
AGENDA 2 > INTRODUCTION TO CI AND HUDSON > USING STATIC ANALYSIS IN PROJECTS > DEMO OF STATIC ANALYSIS IN HUDSON
A short introduction to continuous integration 3 > Continuous integration (CI) is the practice of integrating early and often Developer checks in new or modified code into the repository CI Server polls the repository for changes and starts a new build if necessary > Basic activities of a CI server Check out the source code into a fresh workspace Compile sources, run tests, package and deploy the product Inform the project team about compile errors or test failures > Advanced activities of a CI server Measure the quality of the unit tests with code coverage tools Measure the quality of the source code with static code analysis tools
Hudson is a user friendly open source CI server 4 > Easy installation (only one executable, no database, automatically installs jdk, maven, ant ) > Easy configuration (Web 2.0 UI with validation, no XML configuration) > Web 2.0 UI to visualize the build results > Support of all popular revision control systems > Integration of various issue tracking systems > RSS, E- mail, IM integration > Distributed builds > Integrated Maven 2 support > Open Source (https:/ / hudson.dev.java.net) > Ex tensible (more than 100 plug- ins are available)
Hudson supports all important Java tools 5 > Static Analysis and Compilers Checkstyle FindBugs PMD and CPD Javac JavaDoc Eclipse Compiler Crap4J JavaNCSS (Sonar) > Testing JUnit Cobertura Emma Clover TestNG Fitnesse Grinder Selenium WebTest
How to apply static analysis in projects 6 > Basically two options are possible when using static analysis tools a) Monitor the results (in your IDE or Hudson) and use them in code reviews b) Enforce zero warning projects (i.e., fail a build if there are new warnings) > Drawbacks of option a) Broken window effect: if there are too many warnings, the developers will ignore them at some point It is difficult to distinguish new warnings from ex isting ones in reviews > Advantages of option b) Self- healing since developers don t want to be blamed for failed builds Easy detection of involved change sets
Best practices to obtain zero warnings projects 7 > New Projects Start with complete set of warning rules (CheckStyle, FindBugs, PMD) Fail a build as soon as there are new warnings Discuss the warnings with the team (find an agreement to either fix the code or remove the affected warning rule) > Ex isting projects Spend the time to fix these warnings Use a small subset of warning rules (e.g., only severity high) Use different rule sets for existing and new projects
A strategy to obtain zero warnings in an existing project 8 > In our team we use a combination of these best practices Check existing projects with all warning rules Select the most important ones Recheck projects with the reduced set of rules Spend some time to reduce the number of important warnings For the remaining warnings use suppression warning filters > Policy when modifying code in one of the old modules Consider old projects read- only Move code to new projects if possible (dependencies) Remove suppression warnings filters Fix all warnings before check- in
Static analysis in Hudson 9 > DEMO
Hudson provides a quick overview of a project s quality status 10 > Each project has a health status that is computed from the number of successful builds in the last couple of days the code coverage of the unit tests the number of warnings in the source code > A build can be set to failed if too many warnings are found (total or new)
11 Various graphs show the historical trend of a project or Maven module > Number of unit tests per build (failed or total) > Coverage per build (package, class or line coverage) > Total warnings per build (with severities distribution) > Total warnings per build (with build health thresholds) > New and fixed warnings per build > Difference between new and fix ed warnings per build (cumulative)
12 A summary page shows the important results of each build step
A summary table aggregates the warnings 13 > Warnings are aggregated in several ways Warnings per module (derived from build.x ml or pom.x ml) Warnings per package or file Warnings per category or type
Warning messages are complemented by detailed descriptions from the manual of the analysis tool 14
Warnings are listed in a table 15 > Sortable table with all warnings > Separate tables for new and fixed warnings as well as per severity > Tooltip shows the message with the detailed description > Links to the source code
Warnings are visualized in the source code 16 > Highlighting of the warnings in the source files Java syntax highlighting Warnings can span multiple lines Multiple blocks per warning Warning message in tooltip Warning details from the manual or homepage of the analysis tool > Source files are stored for each build
Future prospects 17 > Interaction of the individual tools (combined graphs and thresholds) > Multi project analysis > Display of warning suppression filters (@SuppressWarnings) > Smart handling of projects with thousands of warnings > If you have any feature requests: https:/ / hudson.dev.java.net/ issues/
Dr. Ullrich Hafner ullrich.hafner@gmx.de Avaloq Evolution AG www.avaloq.com