Feeds

back to article CruiseControl builds for the Enterprise

If there is one concept that is central to the Agile development process, it's probably Continuous Build. Although small projects can rely on manual builds, automation is the key to using Agile for ever larger projects. If you're into Open Source, as many Agile developers are, one continuous build tool of choice is …

COMMENTS

This topic is closed for new posts.

Waste of time

If you are already agile and have been doing continuous integration without Cruisecontrol then I would like to save you some time.

CruiseControl standard was a real pig to use and possibly the most complex wrapper you can imagine for an ant script. Given that the word "enterprise" usually translates in IT to "pointlessly complex" I do not really hold out much hope that they have significantly simplified things in the Enterprise Version.

What does it offer the agile developer?

* It runs unit tests after a commit to version control - If you are really agile you run the unit tests before you commit to version control. Not, after the rest of the team has already checked out your bugs! And if you have hundreds or thousands of unit tests then you will probably find at least some of them break as you get them running in a slightly different environment (eg, outside of your IDE) for integration with CC - this can take a while to get working and by the end of it you wonder if all the hassle was worth it.

* It runs integration tests - This can be somewhat useful if your integration tests are very slow, but of course you still need to write them and there are other much simpler ways to runs integration tests than spending a day trying to get everything running under cruise control.

* Front end tests - If you are doing a web project you can theoretically integrate selenium tests in, but doing this in CC is a hassle and the testing is usually quite fragile. Once again, if you are bothering to maintain good front end tests, then run them before you commit that way when they break you can fix them as part of your changes, rather than run back after breaking the build for everyone else.

* It does a build. - If your project is too massive to build and test fully before committing then maybe CC could be of value, but really I don't personally know any agile developers who would commit code that didn't even compile, particularly with modern IDEs like eclipse show a big red error mark against the project folder and keep code compiled all the time.

I can see a place for an automated build system in very large distributed projects or to try and move non-agile teams in a more agile direction (this is where CC is usually set up - not in teams that are already agile) but I really hope for these enterprises something a bit simpler exists and that the experience of setting up CruiseControl doesn't put them off the whole idea of Agile development!

0
0
Anonymous Coward

Cruise Control - you should be using Continuum

If you are looking at going agile you should be componentising your applications.

Think of a component as a unit of work thats very cohesive and can be expressed as an archive - for example a jar (ear/rar/war) file. It will have dependancies on other archives.

Maven is the way to control how each of the components use and relate to each other.

To build your components you really need a build system that understands how the components relate to each other - Continuum does this.

Have a read http://maven.apache.org/continuum

0
0
Jez

Re: waste of time

Matthew - I see two separate criticisms of CruiseControl

1 - it doesn't do anything useful if you are following agile practices like running the build before checking in

2 - it is a pain to install and use

To answer 1 - one of the major principles behind continuous integration is to run the build on a non-developer computer to check it works on a (more) production-like environment. Running your tests before checking in won't catch things like failing to add new files to source control, or forgetting to update a dependency. Also, if your deployment process consists of more than just building a jar (and most do), then making your CI server package and deploy your app and run tests on this as part of the build process can save you a lot of time further down the line. I'm a bit mystified by your assertion that teams who are experienced agile practitioners don't use CI servers - I've never been on an good agile team without one, for the simple reason that it is a really useful tool when you automate things like the deployment process and acceptance/regression testing. Plus of course as you say it's pretty much a necessity if you're on a large or distributed project.

To answer 2 - CC has improved in terms of usability and configurability in leaps and bounds since a couple of years ago. One of the major things that has been added in CC 2.7 is web-based GUI configuration. For instance you can now add new projects through the GUI if you're using Subversion as your source control system. The team is planning to do a lot more work on this - usability is very important to us.

Thanks for your feedback and happy coding.

Cheers,

Jez Humble.

Delivery manager,

CruiseControl Enterprise

0
0

Re: waste of time

I'm afraid I'm going to disagree that it's a waste of time - certainly for larger projects.

At work we use CC.NET as our build system, and I'm not sure I could survive without it.

One of the biggest advantages for me is that, while I'm working on some low-level bit of the project, I don't need to bother checking out and building the huge amounts of dependent code that sits on top of my component. Instead, every now and again, I grab a build from the build server, unzip it locally, and run with that.

Sure, I could grab all the source from the SCCS, and end up with a huge solution in Visual Studio, but there's no need.

It also makes life far simpler for the testers: they don't need to spend time configuring the build on their machines, they just grab a build from the CI server.

Another advantage is as a "point of reference" for bug reports. If someone raises a bug, they have a definite build number, which greatly simplifies tracking down the problem. When the bug is fixed, it's resolved as "Fixed post build xyz", and the testers can know when to expect that fix to be in place.

As for CC being hard to configure, I haven't had to work with that side of things. I'm thankful to our build manager for handling that for us!

Rob

0
0
Anonymous Coward

Re: Cruise Control - you should be using Continuum

Guess what: you can run Maven from CruiseControl too!

In fact, Continuum has no significant functionality that isn't in CruiseControl, but CruiseControl supports about twice the number of source control tools and publishing methods. Compare and contrast here: http://damagecontrol.codehaus.org/Continuous+Integration+Server+Feature+Matrix

0
0
This topic is closed for new posts.