Lets start with a definition from Wikipedia:

Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. ... The main aim of CI is to prevent integration problems, referred to as "integration hell" in early descriptions of XP.

Martin Fowler defines it as:

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.

So, the idea is to not go too long without integrating your changes with the rest of the team. This way, when its time to release, we know that everybody's code is already working together and all tests are passing.

This raises some interesting points around process and tooling:

• Source control is required, though if you're not already using it, you've got bigger problems
• How do we automatically check that the code integrates successfully?
• How do we automatically make sure all tests are passing?
• How do we handle features that are not complete and we know won't integrate?
• What do we do when integration fails?
• How do we know that integration has failed?

In my next series of posts, I plan to explore these points/questions in detail. I'll cover various processes/workflows that make CI possible as well as tooling that make our lives easier.

Come along on this journey with me, and for those of you with extensive experience in CI environments, I'm all ears for opinions and advice.