UHCS 2005, slide 1

About Continuous Integration

UHCS 2005, slide 2

Why do you write Unit Test ?

• Improve quality/robustness of your code

• Quick feedback

• Impress your boss ?

• Impress your customers?

UHCS 2005, slide 3

What about Integration bugs ?

Every team member’s code is well built and works fine in isolation but…

… strange things happen when everything is integrated… who is to blame ?

• Problem may be in interaction between works• One person may have stepped on another’s bug,

which may have existed for months

Integration bugs are particularly hard to find and fix. May crop up just before a release.

UHCS 2005, slide 4

Eliminating Integration bugs

1. A single person writes the entire code ?

well, maybe not literally, but virtually….

Continuous integration: The entire code base and testing framework is maintained and updated as if it was one unit.

Most “integration bugs” are noticed instantly and time spent on them reduces dramatically.

UHCS 2005, slide 5

How often should we Integrate?

i.e., how often should you check in ? build ? test the entire application ?

• Once a week, once a few days, nightly builds, every 5 min ? End of project “big bang” integration ?

• Integration is a lot of painful work, so it should be done as infrequently as possible. Otherwise you will never get anything done.

UHCS 2005, slide 6

Integrate early and frequently

• Why do people postpone integration?– Under too much pressure

– They don’t have time for it

– Don’t want to be distracted by that

– Don’t have necessary parts installed

– Note enough compute horsepower

• Solution is to automate the integration process as much as possible

UHCS 2005, slide 7

Continuous Integration

• Run test cases when ever code change is checked in or as soon as possible

• When code is checked in the code is compiled automatically and all tests cases are executed– If a test fails the team is alerted

– When test fails, nothing else important/high priority

• Fix the code to make the test succeed

• Or modify the test to fit the changes if appropriate

UHCS 2005, slide 8

More on Continuous Integration

• Clearly all files should be in a single configuration management system

• Build scripts to automate building• BVT Tests – not same as acceptance tests.• You may want to not write any code until there is a

test that fails (XP ?)• Frequent check ins

• It will not eliminate all integration bugs, but the time saved should far exceed time spent ?

UHCS 2005, slide 9

Tools for Continuous Integration• Anthill

http://www.urbancode.com/projects/anthill/default.jsp • Cruise Control/Cruise Control.NET

http://cruisecontrol.sourceforge.net/ • Draco.NET

http://draconet.sourceforge.net/ • Gump

http://jakarta.apache.org/gump/

References:1. "Continuous Integration," Martin Fowler, Matthew Foemmel,

http://www.martinfowler.com/articles/continuousIntegration.html. 2. "Continuous Integration Server Feature Matrix,"

http://docs.codehaus.org/display/DAMAGECONTROL/Continuous+Integration+Server+Feature+Matrix.

UHCS 2005, slide 10

Demo