(1) Introduction to Continuous Integration Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences University of Hawaii

(2) Objectives Understand the motivation for continuous integration. Become familiar with how to best integrate continuous integration into our practices. Become familiar with Hudson, one very popular open source CI technology.

(3) Motivation When many people are working on a project in parallel, there is an “integration problem” How to ensure that the work done separately can be “integrated” successfully. Levels of the integration problem: Merge conflicts: people have modified the same file concurrently. Compile conflicts: No merge conflicts, but people have modified files concurrently such that the resulting system does not compile. Test conflicts: No merge conflicts, no test conflicts, but people have modified files concurrently such that the system does not execute successfully.

(4) Integration can be time consuming In some development organizations, groups may work independently on separate “branches” of the system for many months. For example, one group might work on the “navigation system” for an aircraft, while another might work on the “flight control system”. When these two branches are “integrated” into a single working system, there may be months of work involved in resolving hidden inconsistencies.

(5) Basic Concepts of CI The system must be able to be built and tested automatically. The system must be under configuration management. Everyone commits their changes frequently (every day or two). Upon commit, the system is immediately and automatically “integrated”: Compiled, tested, etc. Problems are uncovered and developers notified.

(6) Benefits of CI Reduced risk: system always builds, or else you know it immediately. Bugs and problems discovered closer to the point in time that they were introduced. System is deployable more frequently, enabling more user feedback.

(7) CI in 413 Your systems can be built and tested automatically. Your systems are under configuration management. You hopefully commit your code frequently. However, no automated integration! Problems only discovered when next person SVN updates and runs verify. We can do better!

(8) Hudson

(9) What Hudson does Runs as a server. I have set one up in my lab for you to use. You can define “jobs” to do CI. For example: Connect to Google Project Hosting every 5 mins. Check to see if any changes have been committed. If so, - Check out changes. - Build the system. - Run JUnit, PMD, Checkstyle, FindBugs. - failures to your discussion list.

(10) Hudson & verify.build.xml Both are useful and complement each other. You still want to run verify.build.xml: Before committing changes. After updating your local workspace. Hudson adds extra safety: If you forget to verify, hudson will remember. Sometimes verify works on one machine and not another. Hudson helps discover this quickly.

(11) Setting up a Hudson task Login Define the job. Add to your discussion list. Do a test commit. Check to see that the build is triggered. Test a “bad” commit to see that mail is generated.

(12) Login

(13) Create Job

(14) Provide a description

(15) Provide SVN URL for READ- ONLY access! ( not

(16) Poll SVN every 5 minutes

(17) Invoke “ant -f hudson.build.xml” Ant is invoked only if polling SCM has found changes since last build.

(18) What is hudson.build.xml? Can by very simple to start with. Just invoke verify!

(19) Test “ant -f hudson.build.xml” locally

(20) SVN add your new hudson.build.xml

(21) Send to your discuss list Be sure to add to your discussion list membership!!

(22) After saving your configuration, Hudson will immediately try to build Check your build history to see what happened!!

(23) Build #3 (Manually invoked) Check “Console output” for the build record.

(24) Console Output for Build #3

(25) Commit a busted file to test failure

(26) Within 5 minutes, it should start to automatically build

(27) Build Failed!

(28)

(29) Check discussion group for

(30) Don’t forget to fix your code!

(31) Configuration issues Why hudson.build.xml? Why not invoke verify directly? Local manual verification and automated CI tend to diverge slightly over time. Start by making them identical, but enable each to evolve independently. Why send to -discuss? Why not developers directly? The developers in a project can evolve over time. By sending the info to the list, you don’t have to maintain a membership list inside Hudson.