Getting Started With Continuous Integration

by Uwe B. Meding

Continuous Integration (CI) describes the practice of automating the build, testing and deployment of your software, so that producing a finished executable and/or related artifacts can be done at the touch of a button, and is ideally carried out several times a day. CI is one of the core agile practices, and equally as important as version control and unit testing.  If you are completely new to the idea of CI, you may want to check out my other blog post “Making the Case for Continuous Integration” or  “Pragmatic Project Automation” by Mike Clark first.

Primarily, CI does not assume any particular platform, but does require some level of planning. There is no one-size-fits-all strategy to this, however here are some good questions to get you thinking:

• What to put under CI control?
• How often to integrate?
• How long does a build take?
• What to do when a build is slow?

Probably the simplest way to get started is automating regular builds, tests, and deployment of your software. Once this routine is embedded in your development process, you can leverage this process for advanced practices such as enforcing code styles, recording code metrics, static analysis etc. In time you will create more robust code, develop more rapidly, improve testing, deploy more reliably, gain confidence with your software, and save money.

Look at a typical software development workflow, which goes approximately like this:

1. Write some code
2. Test the additions/changes
3. Fix bugs
4. Deploy or release
5. Hope that nobody finds any new bugs
6. Rinse and repeat

Of course this is hyperbole, but lets take a step back and understand what we can accomplish with continually integrating our software. The basic idea of CI is that we integrate out product as soon as we make a change to the code base. This means that we will never deviate too far from the main code branch and have feature addition or bug fixes pile up. The obvious advantage is that at any given time we have a working (and possibly finished) product ready to be shipped.

How do we get started?

1. Make sure all your software and required files/data is under version control
2. Make sure all your (unit) tests are also under version control
3. Get a continuous integration tool, or sign up for a hosted tool

Basic Continuous Integration

1. Check the code repository for changes. This can be done on a regular schedule (say every hour), when a code check-in is detected, or we kick it off manually. There are quite number of ways that all continuous integration support. Which one you pick very much depends on your project and how it is integrated.
2. Build or compile the code. The premise is that the code can be build automatically, and without human intervention.
3. Run your tests: unit, regression, and so forth. There are two assumptions: first, we have tests we can run; and second, they can be run without human intervention.
4. Alerts if we detect any problems.
5. Gather metrics if appropriate

The benefits to your software development efforts are immediate. The Continuous Integration systems run all the time, and unlike a human, never get bored doing builds and running tests. Its ability to catch problems fast gives us rapid feedback after every change. Alert notifications can be given to developers when something breaks, all while the code is still fresh in their minds. This prevents bugs from propagating downstream by catching them early on when they are still cheap to fix. Once we are in the QA phase or even deployment, any issues become a lot harder to address and the risk of exposure increases rapidly. The critical prerequisite is to have plenty of code that tests your code, and with a continuous integration system at your disposal you can test your application much faster and more reliably than by just clicking around.

Philip von Weitershausen has a great presentation Untested code is broken code

What is the next step?

The first question to answer is: do you prefer hosted vs. hosting it yourself? Either approach is perfectly valid. Which one you chose depends very much on the projects and the projects dependencies. Questions to keep in mind:
What external dependencies does the project have? For example,

• do we require access to a particular database? Is it publicly accessible?
• do we require special equipment?
• do require access to web services, etc.? Are they publicly accessible?

Popular hosted solutions

Travis CI is a hosted, shared continuous integration service used to construct and assess projects hosted at GitHub. The continuous integration software is also available as an open source download on GitHub. Travis CI automatically identifies when an action has been executed and launched to a GitHub archive using Travis CI, then will attempt to build the project and perform tests. This includes commits to all branches, including the master branch. When that process has completed, a developer will be alerted in the way it has been configured to do so.

Bambo, by Atlassian, is a Continuous Integration software tool that aids software engineers in the process of merging all developers’ working copies together with a shared mainline multiple times daily. Bamboo not only controls builds and tests, the software links issues, executes, assesses results, and sets up so the whole picture is available to an entire project team.

Popular self-hosted solutions

Jenkins CI is the leading open-source continuous integration server. Built with Java, it provides well over 800 plugins to support building and testing virtually any project. It runs in a servlet container, such as Apache Tomcat. The continuous integration tool supports SCM tools including CVS, Subversion, Git, Perforce, Clearcase and RTC, and can execute Apache Ant and Apache Maven based projects, as well as arbitrary shell scripts and Windows batch commands. Builds can be initiated by numerous processes, including scheduling through a cron-like structure, constructing when other builds have concluded, and by requesting a specific build URL.

TeamCity is an another pre-integrated solution. It supports Java, .NET or mobile development platforms. There are over 100 plugins to assist the build and intergration of a project. It integrates well with the more traditional approach to Continuous Integration, or Feature Branches with Git or Mercurial.

One final word of caution: Continuous Integration is no replacement for a lack of craftsmanship and understanding your daily work and its details. It is a really powerful tool that automates much of the necessary drudgery in engineering a world-class software product. Nothing more, nothing less.