In a programmer’s mind

A small robot giving you a hand by woordenaar

The time has come to get out of the integrated development environment mindset. Software development should not be based on a monolithic piece of software like the IDE. In the beginning, I though it was great to have all those tools within a click away easy access but the more I think about it, the more I am repulsed by it. I want to be independent from that easy build button. It seems like it does not find with that mindset.

In my never ending quest for better software quality, I got interested by the continuous integration process. Before getting too deep with the matter, let’s try to define what is the integration process in a software development. Integration happens when you make a change to your software and you want to make sure everything works with the software you had before and that your change conforms to some quality standards. A change can be a lot of different things like adding a simple message, adding a module, changing the colour of a box or refactoring your whole application. It can be while starting up your project and developing it, it can be a change during the beta phase or it can be an emergency bug correction for a running application. Whatever is changed, however it is done and wherever it goes, you want to make sure it does work.

Integration can be quite easy for small projects with small changes while being quite hard for large projects with big changes. Continuous integration is about making that process an incremental, routinely done, automated and simple thing to do.

How do it works? You will often have one or many dedicated servers waiting for changes to be included in the source control management system. It can be with a hookup script or with a pull process. Often, you will also see some of those continuous integration servers setup to run some task at predetermined intervals like every midnight. Whether is it event based or scheduled, they will most likely run one or more of the following tasks:

• Building the source
• Running unit tests
• Running a code coverage analysis
• Running a code analysis for standards conformity
• Running a performance analysis
• Generating code from a model
• Building the documentation
• Deploying the results on a test server

For each task, the server will keep a report on what happened, how did it go and what are the results. For instance, for the unit tests task, you might want to have a report with how many tests succeeded, how many failed and which one failed. A concrete example would be the waterfall view for the Google Chrome continuous integration process.

There are many advantages to use a continuous integration process. The most important one is to find bugs early and correct them early.

Let’s say you configured your continuous integration server to build your source whenever you commit a change in your source control management system. If you commit a change that breaks the build process, you can be notified quickly that you did something wrong and correct it. The cost of correcting a bug is often proportional with the length of time from the moment it was introduced to the moment it was found.

There are many solutions both open source, free and commercial ones available to fill your needs. BuildBot, CruiseControl are some of the popular ones. A simple script might also be the best thing for you is not much is wanted.

With the quality goal in mind, a proper continuous integration process is a must.