Continuous integration has established its place among the good software development practices. However, setting up a continuous integration server and configuring it to run your tests automatically does not mean that you are really doing continuous integration. It only means that you have installed a continuous integration server and it run your tests automatically. Martin Fowler defines continuous integration as follows:
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.
The goal of continuous integration is to minimize the impact of problems found when integrating different software components together. A regular integration cycle ensures that the components are integrated together in small pieces. The advantage of this approach is that you don't have to deal with large problems which might be troublesome to solve. Instead, you will face only smaller problems which in general should be easier and faster to solve. A failing test is an indicator of a such problem.
The true test which reveals if you are really doing continuous integration is this: What do you do when your build fails? If you are doing continuous integration, you will start fixing the problem as soon as you are aware that it exists. This is the condition which must be fulfilled before you can claim that you are doing continuous integration without lying. Keeping your build green should be your first priority because:
A green build signals that the code is working. At first this might seem like an answer given by a smartass but knowing that a build works has two advantages:
First, it helps developers to isolate the cause of problems they might face when they are adding more code to the code base. If they can trust that the code was working before they made changes to it, they know that their changes are the cause of their problems. Any developer who has worked with legacy code knows how valuable this is and how much time it saves.
Second, a green build is a good way to find out which parts of the developed software are done. In my opinion, the only way to verify that a code is working, is to write comprehensive tests to it. When those tests passes, you know that the code is working and you can start working on the next task on your to-do list. If you do not write comprehensive tests to your code or you decide not to write tests at all, you cannot know whether it works or not. And to make matters worse, you cannot know whether your code is working one month from now.
It prevents the situation from escalating into something much worse. You might have heard about the broken windows theory which states that taking a good care of urban environments may prevent vandalism and reduce the possibility that the situation would escalate into more serious crime. In my experience this theory can be applied to software development, and especially to continuous integration. If you don't take failing tests seriously and fix them as soon as they appear, the developers get used to the situation. They start to think that a failing build is not such a big deal.
When this happens and you do not react, you will eventually end up in a situation where a lot of tests are failing and you are forced to figure out why (or ignore them forever). If the situation gets this bad, fixing it will last a lot longer than fixing a single failing test (Remember that fixing the failing tests is not enough anymore. You will also have to fix the attitude of your developers). In my experience, it is not wise (or pain free) to figure out how much longer it takes. Instead, I recommend that you choose to keep your build green. It is not just the easiest way. It is the only way.
I have now described to you why keeping your build green should be your first priority. A word of warning though, a green build does not guarantee that your software is bug free or that it is working. It only guarantees that the code compiles and that each test case passes. If you want to enjoy the benefits described in this blog entry, you must ensure that your test suite is in a great shape. And if you don't have a proper test suite, start building one right now. The benefits of having a great test suite and keeping your build green are far greater than the so called benefits of any excuse you can make of.