Methods & Tools Practical Continuous Integration Kim Gräsman & Jonas Blunck, TAC AB
Integration Merging your latest changes with the common code base
Integration problems Forgetting to add a file Conflicting changes Environment dependencies Problems increase the longer you wait to integrate
Symptoms of problems Code base hard to build on clean machine Build often fails when a release needs to be put together Conflicts occur regularly when approaching release Integration takes a long time
Continuous Integration Integrate and verify changes as soon as possible
Ground rules Always keep common code base in a working state Integrate one at a time Verify every integration on clean machine Notify everyone of integration results Don t allow almost works
Source code Integration status Build and test
CruiseControl.NET An integration server developed by ThoughtWorks, Inc. Open source license Available at no cost
CruiseControl.NET 1. Poll source control for recent changes 2. Execute build tasks 3. Report on status during the entire process 4. Publish the build results
Source code Integration status Build and test
Demo
Extending CruiseControl.NET Log build tool output to XML Merge XML into build log Display in web dashboard using XSL
Demo
Experiences
Managing CC.NET paths Ultimate root is server working directory Project can set its own root, relative to server working directory Tasks execute relative to project working directory
Managing CC.NET paths NT service: working directory at ccservice.exe Console: working directory varies (%CD%) Run ccnet.exe through a.bat script to force specific working directory
Minimize CC.NET config Smell: CC.NET config contains many project-specific details Makes configuration fragile if project changes ccnet.config grows huge
Minimize CC.NET config Try to collect all dependencies and source under a single source control root Move details to build script in project source root directory Build separate CC.NET bootstrap script that checks out project and calls its build script
Minimize CC.NET config Build script can now be tested without CC.NET Good way to perform local integration test before committing Details no longer in ccnet.config Drawback: Usually some amount of duplication between ccnet.config, bootstrap and build.
Demo
Too many CC.NET projects Common mistake: one CC.NET project per VS project They are not the same A CC.NET project builds any number of VS projects and other components Produces a deployable system
Too many CC.NET projects Poll one source root and execute one build script per product The build script can do any amount of work Again: the output should be as close to a final product as possible
Too many CC.NET projects Multiple products competing for build resources? Scale out onto multiple CC.NET servers Join reports on a shared web dashboard
Configuration in version control Seamless, versioned configuration Can easily revert back to working state Anybody can make improvements Self-contained system, including binaries for build tools and CC.NET Easy to setup local environment
Demo
Recommendations Play by the rules Fix broken builds immediately Never integrate while building Never integrate into a broken build Check in/commit often Do local updates frequently
Recommendations Keep build time as short as possible Store configuration in source control system Choose a fast source control system
Resources CC.NET project page http://sourceforge.net/projects/ccnet CC.NET documentation http://confluence.public.thoughtworks.org/display/ccnet Continuous Integration defined http://martinfowler.com/articles/continuousintegration.html Presentation resources http://www.blunck.se/practical-ci/ http://www.winwonk.com/practical-ci/
Remember! Enter the evaluation form and be a part of making Øredev even better. You will automatically be part of the evening lottery