Continuous Integration

Automatic build and integration.

Principles

To fix a broken build must always have highest priority. Otherwise, most of the benefit of doing continuous integration is lost.
Integrate often
When deciding which product to use and which CI strategies to implement the goal is (and must always be) to maximize value gained. To illustrate:
- "install productX and all your problems will be solved" <- of course not
- "hourly and nightly builds is the best CI strategy" <- of course not, which CI strategies to implement always depend on the project.
- etc.

Continuous Integration Server Farms (distributing builds)

Building, testing, generating reports is tedious work for the CPU and Memory of a server. Even though it might seem tempting to centralize the configuration of a the CI-strategy in one CI-system, this does not scale far beyond a couple of projects. The CI-server will become a bottleneck, and developers will be waiting for hours to get their builds complete.

There are two alternative solutions to this:

Set up one CI system on a new server for each project.
Set up distributed/remote build agents for the centralized CI System.

Not all CI systems support the second feature. Among those who do are Hudson:

http://wiki.hudson-ci.org/display/HUDSON/Distributed+builds

.. and Bamboo:

http://confluence.atlassian.com/display/BAMBOO/2.1+About+Agents+and+Capabilities

An illustration of a working centralized environment is displayed below:

Revision	Timestamp	Committer	Project	Build time	Message	CI-server	Status	Commands
262 - changes	13:05	Ferris	Petshop	3:39	Introduced some warnings, silly me..	continuum1	Warnings	Notify - Revert
261 - changes	12:56	Ronnie	Demo	3:35	Fixed some other stuff	continuum3	Successful	Notify - Revert
260 - changes	12:54	Kjartan	Petshop	3:35	Reverted r259 because it broke.	continuum2	Successful	Notify - Revert
259 - changes	12:45	Ferris	Petshop	3:50	Fixed some stuff.	continuum1	Errors	Notify - Revert