In my last post I talked about the basics of continuous integration and the need for source control.

Now I want to talk about CI Servers. This topic is probably what most developers think of when CI is mentioned, though as I said in that post: a separate server is not technically required, it just makes your life a lot simpler.

Let's start with a refresher on the steps of continuous integration:

1. Fetch the latest version of the code from your source control repository
2. Make changes on your machine (including tests)
3. Compile/Build and make sure your changes work
4. Run the tests to make sure you haven't broken anything
5. Get the latest changes from your team mates and merge them into your changes
6. Repeat steps 3 & 4
7. Push your changes back to the shared repo

So, where does a CI server fit into this?

Steps 1 & 2 are obviously up to you. One could argue that steps 3 & 4 can be handled by the server, and they are implicitly, but again that's actually your job. The CI server's main job is to handle step 6 as well as to do some extra stuff that doesn't make sense for you to do regularly.

Essentially, the CI server does the following:

1. Watch the source control repo for any new changes
2. Fetch the new changes
3. Compile the code
4. Run any tests
5. Report on the result
   
   • Usually via an email or some sort of dashboard in your office

The server will perform these steps over and over, on every single change made to the code. That will save you a lot of time, but it's the other jobs it can do that will save you even more and make your code quality much more visible to you and your team:

• Run long-running integration tests regularly
  • I've worked on teams where these tests take an hour to run, you don't want to have to run those on your machine befor every commit
• Generate test coverage reports
  • These can technically be run on your machine, but can add unnecessary time to your local build
• Generate statistics on code quality
  • These can technically be run on your machine, but can add unnecessary time to your local build
• Other long-running tasks

The server can even be setup to then deploy the working code to a QA environment, or even to production, but we're getting ahead of ourselves here, I'll cover continuous deployment in another post.

At Entelect, we have quite a few large TVs set up around the office. They all display the current CI status of all projects currently in development. This gives us instant visibility when a project fails as everyone is made aware. We also generate some cool stats like the percentage of successful vs failed builds for the day/week/month. We even have a tradition where, if a developer breaks their project, they have to wear a funny hat until it's fixed :D

Each team may work differently, but having a centralised server doing the building opens up a lot of possibilities. I'll also touch more on our dashboard in another post (I wrote it for an internal competition).

My challenge to you is to get a CI server set up in your environment. There are plenty of free & paid for options:

• Teamcity (by Jetbrains, paid)
  • We use this at Entelect, it is very powerful, supports plugins and has a great API that we use to power our monitors.
• Hudson / Jenkins
  • Open source / free
  • Started as Hudson, but was forked into Jenkins when Oracle took over
  • I used Hudson before the fork, I'm not sure how they've changed since then
• Travis / CodeShip
  • Cloud based CI solutions
• And many more, just Google it :)