If you’re searching for a way to develop cohesive software in a faster way, then the solution might be continuous integration: a software development practise which revolves around each team member frequently integrating their work, sometimes several times on a daily basis.

In this continuous integration guide we take a closer look at how it works, its benefits and how to introduce it in your company.

What is the idea behind continuous integration?

The basic objectives that drive continuous integration are:

• An effort to minimise the effort and duration needed to achieve each integration.
• The ability to deliver a product version ready for release at any moment.

To achieve this, developers should integrate their code using a shared repository on at least a daily basis: and, preferably, several times each day. The check-in process can be verified using an automated build: which in turn allows teams to quickly detect any problems. Through this fast integration it becomes possible to not only find problems faster: but also to locate them and deal with them.

So with continuous integration you can solve problems quickly?

That’s the idea: because with continuous integration there will be substantially less back-tracking in order to find where problems began. Instead, developers can concentrate on building new features.

The belief, at least according to Martin Fowler, is that failing to introduce continuous integration can be significantly expensive. With longer periods between integrations, you are making it harder to find and, subsequently, fix any problems that may exist. These can, in turn, knock a project away from its schedule: or, in some cases, prompt it to fail completely.

So how is continuous integration practised?

According to Martin Fowler there are a number of key practises that will determine whether continuous integration will be successful for your business or not:

• Single source for repository: As a basis to ensuring that continuous integration works you will need several tools, including: a solid source code management system. In this regard, cost should not be an issue as there are a host of quality open source methods available. Among the leading continuous integration tools to choose from are: Subversion and Perforce. When you have a system established it’s vital to put it into a place where it can be easily accessed. It’s also important to have a mainline – this is a single project branch that is being developed. Everyone should be able to work from this mainline throughout the process.
• Build automation: One of the common features of these systems is an automated environment. It is a common mistake for developers to not include everything within the automated build. In fact, the build should feature every detail so that someone could potentially bring a virgin machine, have sources checked, issue just one command and enjoy the system running.
• Self-testing build: A simple way to catch any bugs in an efficient manner is to ensure there are automated tests within the build process. Of course testing will not be perfect but it can potentially catch a lot of issues. Both Test Driven Development (TDD) and Extreme Programming (XP) are highly useful in the execution of this technique.
• Complete commitment: For continuous integration to be successful, it’s vital that each developer commits to the mainline on a daily basis. This will include passing build tests and resolving any conflicts. By doing this on a regular basis, the developer is able to correctly build their code while spotting problems as soon as possible.
• Build the mainline on an integration machine: With daily commitment the mainline should stay in a healthy state: however, things can still go wrong. This is why you should ensure that regular builds occur using an integration machine: and only if this integration is successful can the developer then continue. This could be done using a manual build or a continuous integration server.
• Fix broken builds instantly: The basis of continuous integration is that you are constantly developing a stable base. So if the mainline build were to break then it must be fixed quickly.
• Quick builds: Nothing will slow the process down faster than a slow build. With an XP guideline you can usually enjoy a 10-minute build. Of course continuous integration will slow the process down because it will demand frequent commits: making it crucial to set up a deployment pipeline which will ensure that multiple builds are carried out in a sequence. The trick should be to find the balance between speed and bug finding so that the build will still be solid enough for others to work on.

Fowler also outlines a number of other key stages to continuous integration, including: testing with a clone of the production environment; making it easy for everyone to get the latest executable; and ensuring that everyone can see what is taking place.

So what are the benefits of continuous integration?

Perhaps the most widespread benefit of continuous integration is that risk is reduced drastically. With deferred integration you can get a long way through the process before noticing an error: and then it can be too late to fix it. With continuous integration this problem is removed as blind spots are eliminated and you will know exactly what bugs exist in your system during the process.

Are there any downsides to continuous integration?

Just remember that if you decide to put continuous integration into practise then it is not as simple as just finding continuous integration tools to assist the process: such as Cruise Control, Hudson, etc. Instead, continuous integration should be based on a complete change in attitude among developers rather than simply implementing new tools: it will take a true team effort to reap the rewards.