As we near the end of the year it's a good time to look back at how we're doing things and to look for opportunities for improvement. Last year Eclipse.org has taken some significant steps forward. One notable change for the better is the increasing adoption of running builds on a central build server (in this case, Hudson). While red balls look great on the Christmas tree, they can really detract from the benefits of continuous integration.

At my work we've developed a culture that focuses on maintaining a fast, clean build. It is light-hearted and fun: those that break the build are quick to respond and restore integrity. This behavior is encouraged by good-humored ribbing by other team members. This culture takes a small amount of effort to maintain, however the team recognizes that everyone benefits:

  • Integration problems are detected and fixed continuously
  • Early warning of broken/incompatible code
  • Early warning of conflicting changes
  • Immediate unit testing of all changes
  • Constant availability of a "current" build for testing, demo, or release purposes
  • Immediate feedback to developers on the quality, functionality, or system-wide impact of code they are writing[1]

At Eclipse.org we can do the same thing: let's strive to eliminate broken builds entirely. Builds should (almost) always be blue; when they're broken, those that caused the breakage should either roll back their changes or fix them.

Here's to a great 2010 at Eclipse.org, where continuous integration meets with continuous improvement!