views:

1239

answers:

5

To ease our release testing, we're looking for a system to automatically build and (unit) test our software projects on a variety of architectures. Our constraints are:

  1. The code to build is written in several languages, including Python, Java and C.
  2. We have several distinct deployment architectures.
  3. We have multiple projects, which we would like to build and test independently.
  4. Our source control system is Subversion, and the system should integrate with that.
  5. The solution should ideally be open source.

We've looked at:

  • Artifactory + Continuum: Nice in some ways, but is heavily Java-centric, with limited or non-existent Python support.

  • Buildbot: This gives us almost all the functionality we need, except it doesn't support multiple projects, which is a deal-breaker for us.

What would you recommend? What do you use?

+3  A: 

Have you looked at Hudson? I've used it on .Net projects with a lot of success even though its a somewhat Java centric tool. It supports subversion and has an active and diverse plugin community which enables it to work with a lot of different languages. Its open source and it runs on many platforms.I found it to be relatively easy to configure and manage.

Dan Rigby
I've been prototyping this, and it seems like it could fit the bill. Accepting this answer as there don't seem to be many other good alternatives...
ire_and_curses
+1  A: 

Since moving away from buildbot i've been using cruisecontrol and i've been happy with it to certain degree. My current projects consist of building c++ & ruby (with some c extensions) to multiple architectures and and only gripe with is that most features do require ant. And currently single instance of cc is building roughly 40 different projects.. Build phases we have do consist of running unittests, some functional tests, getting code coverage and making a report of those, updating package database, irc integration, software packaqge creation and repository update (debian)

Only gripe is that most of the fancier features would require that (Atleast when inside cc build loop) build is happening with ant.

I've also evaluated hudson, it seems to be somewhat more flexible than cruisecontrol but i dont personally like the configuration interface of it.

rasjani
PS. Reason for moving away from buildbot was also to the configuration be "so flexible" that the initial setup takes actually quite a lot of time. So far, i still do think that its the best choice for bigger projects thou.
rasjani
Rasjani, it would be pretty easy to port most of those fancier CC features to the other builders. Post about it on the cruisecontrol-user mailing list and maybe we can get those added for you.
Jeffrey Fredrick
Jeffrey: I'm active on the mailing list and i've submitted my share of suggestions. But the overall vibe is that since im using "unorthodox" setup, eg, im not using ant, most of my stuff has been just ignored. But that said, im happy with the software, i can patch my setup to degree that it does what i need so im still a happy camper =)
rasjani
+1  A: 

I'm a developer on CruiseControl and I work for Urbancode who makes AnthillPro, so I can speak to the strengths of those. I'm also one of the organizers of CITCON so I'm pretty familiar with almost all the offerings in the space.

CruiseControl or Hudson are both pretty good open source CI tools. I find CC really easy to customize and extend and there are lot of plugins that have been added over its 8 year lifetime. Hudson is newer and easier for most people to get started; it is dead simple to get your first project running using the GUI configuration while CC requires mucking about in XML files. Hudson also has an active plugin community and is rapidly adding new capabilities.

However depending on the complexity and requirements of your projects you might find a commercial tool like AnthillPro would be a better fit. The reasons upgrade from CC or Hudson to AHP vary from company to company but some typical answers include the ability to setup self-service deployments with access control by environment, the desire to chain multiple builds/workflows together, the built in dependency management, the artifact repository, or the ability to pull together data from a bunch of different tools & builds across the lifecycle.

Not everyone needs those capabilities but the people who do find the upgrade to be worth the money.

Jeffrey Fredrick
A: 

Why not also take a look at CI Factory.

Ola Eldøy
A: 

Take a look at TeamCity. Works like a charm for us.

keuleJ