Continuous Integration Improving Software Quality with Continuous Integration Continuous Integration In a nutshell Continuous Integration (CI) is: • Assembling software every time code changes CI is important because: • Integrating software often decreases the life-span of a defect Build Better Code Faster © 2007, Stelligent Incorporated 2 © 2007, Paul M. Duvall Continuous Integration in Practice Continuous Integration requirements: • A reliable build process – Ant, Maven, etc • An SCM system – Subversion, Perforce, CVS, etc • A Continuous Integration server – CruiseControl, Hudson, etc © 2007, Stelligent Incorporated 3 © 2007, Paul M. Duvall Life with Continuous Integration 1. Developer checks out working copy of code a. Makes modifications & runs local build i. Does an update 2. If build was successful, checks in modifications 3. Moves on to next task © 2007, Stelligent Incorporated 4 © 2007, Paul M. Duvall Life with Continuous Integration CI server is always listening 1. If SCM is modified a. CI server assembles software i. If assembly fails, CI server notifies interested parties b. CI server posts results and resumes listening © 2007, Stelligent Incorporated 5 © 2007, Paul M. Duvall Continuous Integration Implemented © 2007, Stelligent Incorporated 6 © 2007, Paul M. Duvall Successful CI Process Three prevailing principles: 1. Expand the definition of “software defect” 2. Ensure a short lifetime for defects introduced 3. Extend defect visibility for all stakeholders © 2007, Stelligent Incorporated 7 © 2007, Paul M. Duvall What is a Defect? Is it just not meeting the specification? • Yes, but specifications can be hard to nail down – Can’t validate them until later cycles Expand definition of defect • Create specific gates • Exercise gates earlier © 2007, Stelligent Incorporated 8 © 2007, Paul M. Duvall Expanding Defect Definition Finer grained: • Developer tests didn’t pass – Developer tests weren’t written • Code coverage dropped • Code complexity increased • Coverage dropped and complexity increased! © 2007, Stelligent Incorporated 9 © 2007, Paul M. Duvall Ensuring Short Defect Lifecycle Broaden the value of a build • No longer just a compilation process: 1. Compile 2. Test 3. Inspect 4. Deploy © 2007, Stelligent Incorporated 10 © 2007, Paul M. Duvall Broad Software Builds Broad software builds act as quality gates Inexpensive Continuous Rapid © 2007, Stelligent Incorporated 11 © 2007, Paul M. Duvall Broad Builds Increase Visibility Visibility is transparency • What code changed? • Who changed that code? • How well was the code tested? • How complex was the code? © 2007, Stelligent Incorporated 12 © 2007, Paul M. Duvall Broadening the Build Process Testing is obvious, right? • Does assume people author them! For every build, execute developer tests • Test failure is a build failure • Monitor test velocity as well © 2007, Stelligent Incorporated 13 © 2007, Paul M. Duvall Software Inspections Code reviews are excellent, but • Manual • Error prone • Disappear when schedules are tight Humans focus on high level details Machines focus on low level details © 2007, Stelligent Incorporated 14 © 2007, Paul M. Duvall Software Inspections Machines make code reviews more effective • Cheap to obtain and run – Many open source tools available – Need CPUs to parse files • Output is objective • Interpretation is subjective © 2007, Stelligent Incorporated 15 © 2007, Paul M. Duvall Software Inspection Categories Five primary groups: • Complexity • Duplication • Dependencies • Coding standards • Code coverage © 2007, Stelligent Incorporated 16 © 2007, Paul M. Duvall Code Complexity Complexity correlates to errors • Cyclomatic complexity – Measures paths through code – More paths increase cost to test • Decrease comprehensibility © 2007, Stelligent Incorporated 17 © 2007, Paul M. Duvall Code Complexity Tools Java • JavaNCSS • PMD © 2007, Stelligent Incorporated 18 © 2007, Paul M. Duvall Code Duplication Duplicate code can replicate: • Defects • Poor design & coding Unknown duplication will haunt you © 2007, Stelligent Incorporated 19 © 2007, Paul M. Duvall Code Duplication Tools Java • CDP • Simian © 2007, Stelligent Incorporated 20 © 2007, Paul M. Duvall Dependencies Understanding code dependencies • Facilitates understanding – LOE to change – Brittleness © 2007, Stelligent Incorporated 21 © 2007, Paul M. Duvall Dependency Tools Java • JDepend © 2007, Stelligent Incorporated 22 © 2007, Paul M. Duvall Coding Standards Standards can • Enforce consistency • Increase comprehensibility • Decrease defects via common defect patterns © 2007, Stelligent Incorporated 23 © 2007, Paul M. Duvall Coding Standards Tools Java • Check Style • PMD © 2007, Stelligent Incorporated 24 © 2007, Paul M. Duvall Code Coverage Measuring code coverage • Facilitates understanding what’s not tested • Promotes collaboration between development and QA © 2007, Stelligent Incorporated 25 © 2007, Paul M. Duvall Code Coverage Tools Java • Cobertura • Clover © 2007, Stelligent Incorporated 26 © 2007, Paul M. Duvall Extending Visibility Run inspections often & publish results • Cheap quality gates • Foster accountability • Cultivate collaboration You can’t improve what you can’t measure © 2007, Stelligent Incorporated 27 © 2007, Paul M. Duvall Thank you! Check out • www.testearly.com • www.thediscoblog.com “Continuous Integration: Improving Software Quality and Reducing Risk”, June 2007 © 2007, Stelligent Incorporated 28 © 2007, Paul M. Duvall Andrew Glover [email protected] Blogs: www.testearly.com www.integratebutton.com www.thediscoblog.com.