Continuous Integration

Improving Software Quality with 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

Continuous Integration requirements: • A reliable build process – Ant, Maven, etc • An SCM system – Subversion, Perforce, CVS, etc • A Continuous Integration server – CruiseControl, Hudson, etc

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

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

Continuous Integration Implemented

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

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

Finer grained: • Developer tests didn’t pass – Developer tests weren’t written • Code coverage dropped • Code complexity increased • Coverage dropped and complexity increased!

Ensuring Short Defect Lifecycle

Broaden the value of a build • No longer just a compilation process: 1. Compile 2. Test 3. Inspect 4. Deploy

Broad software builds act as quality gates

Inexpensive Continuous Rapid

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?

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

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

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

Software Inspection Categories

Five primary groups: • Complexity • Duplication • Dependencies • Coding standards • Code coverage

Complexity correlates to errors • Cyclomatic complexity – Measures paths through code – More paths increase cost to test • Decrease comprehensibility

Code Complexity Tools

Java • JavaNCSS • PMD

Duplicate code can replicate: • Defects • Poor design & coding Unknown duplication will haunt you

Code Duplication Tools

Java • CDP • Simian

Understanding code dependencies • Facilitates understanding – LOE to change – Brittleness

Dependency Tools

Java • JDepend

Standards can • Enforce consistency • Increase comprehensibility • Decrease defects via common defect patterns

Coding Standards Tools

Java • Check Style • PMD

Measuring code coverage • Facilitates understanding what’s not tested • Promotes collaboration between development and QA

Code Coverage Tools

Java • Cobertura • Clover

Run inspections often & publish results • Cheap quality gates • Foster accountability • Cultivate collaboration

You can’t improve what you can’t measure

Thank you!

Check out • www.testearly.com • www.thediscoblog.com

“Continuous Integration: Improving Software Quality and Reducing Risk”, June 2007

Blogs: www.testearly.com www.integratebutton.com www.thediscoblog.com