(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/Jenkins, a very popular open source CI technology. Hudson is a very popular open source Java-based CI tool developed by Sun Microsystems. Jenkins is a fork of Hudson that occurred after Oracle bought Sun

(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 compile 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 quickly. 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 ICS SE 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) Jenkins

(9) What Jenkins 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 minute. 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 project team.

(10) Jenkins & 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. Jenkins adds extra safety: If you forget to verify, jenkins will remember. Sometimes verify works on your machine only. Jenkins helps discover this quickly.

(11) jenkins.build.xml For clarity, let’s define a new file called jenkins.build.xml that contains the continuous integration target. For starters, this can simply invoke verify! Later, jenkins.build.xml could do different things than verify.

(12) Setting up CI on Jenkins Login to the Jenkins server. Get the password in class. Define a CI job (by copying wattdepot-simpleapp) to: poll SVN every 1 minute invoke jenkins.build.xml when changes detected. developers when build fails. Do a test commit. Check to see that the build is triggered. Test a “bad” commit to see that mail is generated.

(13) Demo time