Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Continuous Integration at Eclipse.org

DZone's Guide to

Continuous Integration at Eclipse.org

· Agile Zone ·
Free Resource

Download the whitepaper on Product Centric Agile Delivery. Brought to you in partnership with Jile.

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!

From http://greensopinion.blogspot.com

Download the whitepaper on Five dimensions of Scaling Agile in Large Enterprises. Brought to you in partnership with Jile.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}