What the…?! There, I said it. Whew…now I feel better. Maybe this was a provocative blog title and is better said “Effective CI has little to do with your CI server”. Better?
Last year, in an Automation for the people article, I wrote:
“CruiseControl is the granddaddy of CI servers. It’s been available for over five years, and in many ways, the CruiseControl server has become synonymous with the practice of Continuous Integration.”
That a tool has become synonymous with a practice is actually a good and a bad thing. It’s good because there’s a name and an actual tangible thing that we can attach to this practice called “Continuous Integration”.
To be clear, a CI server…ummm, lemme see, it…it…builds your software and then notifies you when it’s done.
However, having a tool synonymous with a practice can be bad thing because people can get carried away with the various bells and whistles different CI servers provide. Don’t get me wrong, I’m a big fan of CruiseControl and other CI servers, but let’s not get lulled into thinking that the tool is what provides the practice. Vendors may want us to think this, but we’re smarter than this, right?
I will have done a disservice to readers of Continuous Integration if you were to believe that the most important facet of CI is the CI server itself. It just might be the most unimportant part of the practice of CI. In fact, as I indicate in the book, some high-performing teams don’t even use an automated CI server for their integration builds (they perform a manual synchronous integration build - which uses an automated build). If someone thinks that the difference between practicing effective and ineffective CI is tweaking the automated CI server to be “just right”, beware…you may be listening to either a theorist or a misguided practitioner. The most important part of the effective practice of CI is the development team’s daily practices (committing code often, keeping integration builds in the green and so on) and the fully automated build from a single source repository. Of course, there are a number of other practices (that we discuss in the book), but “Using a CI server ” is far down the list of importance.
Having actually implemented fully-functioning CI systems (not just the server) on many projects and platforms, I’ve found that installing and configuring the CI server (thanks to many of the great CI servers on the market) is typically one of the more trivial parts of the implementation.
Interestingly, I have found that when teams hear that a CI “server” is being installed, it can help instill or even encourage people to begin employing beneficial development practices that work well in a CI environment, but unless the team culture changes, it’s usually a short-lived gain.
I’ve included a full example of a CruiseControl configuration and a fully automated build (using Ant) with a small working Web application at IntegrateButton.com. Every week, I will add additional videos and examples to the site using different tools (e.g. Hudson in the upcoming weeks) and environments as this is a better and more timely medium than a book to share this information.
Just remember, don’t be the fool with the tool. You can employ CI with or without a CI server.
