Continuous Integration

“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. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly” martinfowler.com

Steve McConnell wrote about doing this in 1996 in Daily Build and Smoke Test

• Maintain a code repository
• Automate the build
• Make the build self-testing
• Everyone commits every day
• Every commit (to mainline) should be built
• Keep the build fast
• Test in a clone of the production environment
• Make it easy to get the latest deliverables
• Everyone can see the results of the latest build
• Automate deployment

Benefits of CI

• CI allows you to develop software faster, better and cheaper.
• Faster: No integration points. Release builds become a non-event.
• Better: Tested early and often. Consolidated metrics though a CI Server.
• Cheaper: Identify defects earlier and fix when least costly.
• Easily repeatable testing.

Risks Of Not Doing CI

• Without CI the team can lack cohesion (incompatible conflicts, different libraries in use, “I thought you fixed that bug 3 months ago!”).
• Lack of Visibility: Not knowing when a build fails or your code coverage.
• Isolation: “It works on my machine!”.
• Integrating late means fixing bugs late, which is costly.

CI will not work if you want to use:

• Nightly Builds.
• Developer Branches.
• Scheduled Integration.
• Building via an IDE.

To get the most out of CI

• Commit early and commit often.
• Never commit broken code.
• Fix build failures immediately.
• Ensure your builds run fast, and fail fast.
• Avoid known CI Antipatterns below:

Continuous Integration: Improving Software Quality and Reducing Risk

• Infrequent check-ins, which lead to delayed integrations
• Broken builds, which prevent teams from moving on to other tasks
• Minimal feedback, which prevents action from occurring
• Receiving spam feedback, which causes people to ignore messages
• Possessing a slow machine, which delays feedback
• Relying on a bloated build, which reduces rapid feedback
• Waiting until the end of the day to commit changes, leading to Bottleneck Commits, which typically cause broken builds and frustrated developers
  
• A build consisting of minimal automated processes, which results in builds that never fail, leading to Continuous Ignorance and delaying integration problems
  
• Hindering build fixes through a preference for Scheduled Builds, rather than frequently building software with every code change
  
• Believing that code Works on My Machine, only to discover problems later in other environments
  
• Failing to remove old build artifacts, which leads to a Polluted Environment causing false positive and false negative error.

Here's a good article on creative alerting (e.g. SMS, blog update, a lighting orb) on automated build status.

Joe Wright on Continuous Integration