Continuous integration: check in early and often. Really, it can be that simple. We make Continuous Integration very complex with tools like Jenkins, TeamCity and BuildBot; at it’s core, Continuous Integration is about sending your work to and from your colleagues in a trickle of many small commits instead of a flood of few, big commits. Guess which is easier to merge?
The trick is, you need discipline. Without the illusory safety of the a private branch, you can’t go breaking the codebase. Use plenty of tests and perform the check-in dance before you commit.
The textbook definition is still Martin Fowler’s Continuous Integration Article.
That approach worked at the beginning: see ‘Continuous Integration on 20 dollars a day’. But now we live in more impatient times, and many teams couldn’t dream of working in such a patient and considered fashion. Hence, we now think of Continuous Integration being the server, and not the process of integrating.
Our understanding of integration is changing, with the rise of Distributed Version Control, and the mainline pattern that Continuous Integration enforced has been abandoned by some teams in favour of a complex workflow implemented in Git [I don’t recommend this]. DVCS has also given rise to the dreaded feature branch, where people believe that they are doing a good thing by branching. This is partly arisen from open source projects, where it may be a boon to have a small feature arrive in one commit. In your company, a small stream of commits may be OK.
Still others sell products that will allow teams to work in branches, yet merge down to a mainline when their work passes; this may be needed if your teams are excessively distributed.
The thing that we haven’t discussed yet is tests. Lots and lots of tests. Testing was easy 10 years ago when you could write many, many fast JUnit tests and execute them in your Continuous Integration build. Those times are mostly gone. You may have hours of acceptance tests, and be forced swamp a grid of build servers to get them to work a reasonable time.
JetBrains introduced the concept of the pre-tested builds that automatically commit in 2007 or so; this adds to the pressure on Continuous Integration.