Which Build-/Configuration Management Tool?

Question

Which build or configuration management tool are you using in your daily programmer's life? Which would you suggest and why? Are you going for Ant? Do you use Maven? Or is there an alternative out there, like Ivy or Buildr?

Answer 1

I work for a .NET shop and we are currently in the process of setting up a Continuous Integration environment to help improve the quality of our deliverables and to give us more control of our releases.

As a first step we are using NAnt build scripts to export code from our Subversion server, build it and deploy it to a test server. Moving forward we are planning to set up a separate build server and using CruiseControl to automatically perform integration testing.

As this is all very new to me, I'm also interested in what tools other developers are using and how they are using them.

Answer 2

I do both .NET and Java, and we use Ant/NAnt with CruiseControl. We have another team that does all C++ and they piggy-back on our CruiseControl server - so it's pretty versatile. I guess the nice thing about Ant<==>NAnt is that it's a common tool if you happen to switch between languages.

Answer 3

In my last project I used Ant as a build tool. TeamCity was our integration server, which would pull the trunk from SVN, run the ant build and the JUnit tests. It works pretty well and is easy to maintain, because the project is rather small.

In my current project we are using Maven and Anthill Pro. We just got started, so I have no idea how it works out in the long run.

Answer 4

If you're comfortable with Ruby at all, use Rake.

Rake is by far the simplest build tool I've had the joy to use. It's a domain-specific-language build on top of ruby, basically ruby with a few constructors for handling file dependencies.

Because it's ruby you get nice backtraces when build rules fail.

Here's simple intro to rakefiles http://rake.rubyforge.org/files/doc/rakefile_rdoc.html

Here's the full documentation http://martinfowler.com/articles/rake.html

It is the most concise build language I've ever used, namely because you have full access to ruby.

Answer 5

If you're comfortable with Ruby at all, use Rake.

How does it compare to Buildr?

Answer 6

NOTE: editing seems to have screwed up spacing.

We currently use Maven 1 at my office. They were early adopters of it 4 years ago. I'd like to migrate us to Maven 2 at some point (unless I find something better - Buildr sounds interesting, actually), but some best practices weren't followed and switching is a bigger job than it should be. I would recommend Maven 2.

The main benefits of Maven 2 over Ant that I have observed are its dependency management (specifically its repositories and transitive project dependencies) and its ability to run goals on many projects at once. Ivy may offset some of the dependency management benefits, but I haven't looked into it. Also, I find that Ant and logic branching aren't very good friends. (If you have optional build steps that are expensive time-wise, handling that takes much more effort in Ant)

The downside of Maven is that it tends to have much less IDE integration than Ant (which is more established).

Regardless of build tool, I strongly recommend using Hudson for continuous integration. (It is easy to setup with Ant and Maven, I am less certain for other build tools but basically if you can call a script you can use Hudson). It's open source and has a very active community and is easily extendable (quite a few plugins for it have been written).

Answer 7

We have been using FinalBuilder to make our builds on a dedicate build machine. We haven't had the buy in from our QA department for continous builds, but that is a long term goal. What I like about FinalBuilder is that we can start and monitor the builds from a web page and we can do the entire build process form source control to building the installer. It's development tool agnostic, so we build our Delphi and .NET projects with it.

Answer 8

How does [Rake] compare to Buildr?

I've used Rake for two or three years, and I use it just about whenever I need to build a project, no matter what it's written in.

However, from what I've read on the Buildr site, it's at least inspired by Rake, and it's specialized for Java projects. I know I'll give it a closer look the next time I've got some java work to do.

From the surface though it looks.. rather complicated frankly. I'm sure I haven't seen any of the more complicated things that can come up in Very Large Java Projects, but a 50 line Rakefile has always been enough to do the job for me. I don't do much Java work.

Rake is simple, powerful, and very easy to extend. On the other hand, it's sparsely documented, and to really get a lot out of it you should be familiar with Ruby.

Answer 9

I've never done this, but I'd imagine you could also run rake under JRuby, which might help with your GIANT ENTERPRISE JAVA integration pain

Answer 10

I can't believe I'm the first person to say this but I use GNU Make for all my C and C++ work.

Answer 11

Java

Maven2 and/or Ant

Ant is great, it is the de-facto standard for Java Projects (Honestly, everybody used it once in their Java Life) but it does have a great flaw: Dependencies. It doesn't do any dependencies management (Which is OK)

Maven2 is great, because you can still use your bits of Ant Scripts but it add dependencies management which is what Maven2 is all about (It can do much more, but dependencies is the #1 reason you want Maven)

C/C++

I personally recommend CMake (The same build management tool used for KDE) since it is cross-platform, very easy to learn and support artifact generation for the most commonly used IDE (Eclipse CDT, XCode, Visual Studio, etc.)

.NET

I have no opinion here... Never used .NET

Answer 12

I'm using Maven 2 + Apache Continuum + Apache Archiva. Continuum is really simply to install and use, but it probably lacks the customization power of CruiseControl. Since I only need a tool that checks for changes in SVN, builds my code, and send notifications when there something wrong, Continuum seems to fill that job.

Answer 13

Java: I like Ant. I prefer to have full access to all the actions being taken on the build. I flirted with Maven, but did not like the concept of giving up some of the control on the configuration. I also found that it forced the download of files that it could sometimes not resolve. (Maybe I will re-evaluate it in order to get over my bad first impression).

c#: I actually like the Team Foundation Server. Although a little pricey, it allows for workflow, continuous integration and automated builds.

Answer 14

We use Gant for our Java work. Gant is the Groovy version of ant, so you can use ant with all the dynamic language features of Groovy. We then feed this buld into the Hudson CI server to perform daily builds.

Answer 15

In my previous company Ant was the apex of build management and we sort of got by.

In my current company we have Maven 1 and it is a massive improvement, not because of some deficiency in Ant (save for the horrible XML build file format) but rather because Maven is being used in a way that makes it shine:

• Maven has a recommended directory layout, your code goes in src/main/java, tests in src/main/tests, resource in ... etc. This sounds like a trivial thing, perhaps even a pain but once you start using it you suddenly no longer have to think about these small decisions that are an absolute waste of brain cycle. And the regularity it brings to your projects is golden. You can find you way around each module instantly.
• Maven manages dependencies as versioned binary artifacts stored a repository: any Maven module is dependent on other modules of a specific version and the dependency is resolved over binary, versioned artifacts stored in a repository (basically a central file server). The significance of this can not be overstated. You are free to evolve your component with wild abandon and other modules can do the same while at the same time depending on each other's versioned artifacts over the repository.
• Single source project definition: by defining your project (where its source is, its tests, what sort of reports to generate, dependencies, etc) in a single canonical place, the Maven Project XML, you cut down on redundancy. Continuous integration tools can use this XML to build your modules and you can generate IDE specific project files from the project definition (Eclipse, Intellij, Netbeans, etc). You can write your own analysis tools that parse this XML and do something interesting with it.
• Huge set of plugins: Maven can be extended with a massive amount of useful plugins. Style checkers (Checkstyle), test coverage (Clover, Emma, etc), and many more.

That is not to say that Maven is not without its faults: its XML configuration format is still too verbose, it can pull in a ton of extra dependencies when doing a simple task like building a module (although this is usually just the first time) and you do need to set up a repository. But the advantages by far outweigh the disadvantages.

Also, as an aside, Maven + OSGi is a huge win.

We are currently migrating to Maven 2 and I would strongly recommend to also go with that version, Maven 1 has been on ice for a while and enjoys very little active development.

Answer 16

I've just migrated our team's build infrastructure from home-grown Unix scripts building Eclipse-based plugins to Hudson + Gant.

Hudson is a fantastic product and puts a smile on developers' faces when I demo it to them. It has an AJAX-based web interface that has a lot of cool touches.

It comes as a self-contained WAR (Java Web ARchive) file and has an embedded web server, so you don't need anything else to run it except the command:

java -jar hudson.war

It has a plugin architecture and many existing plugins. We currently use plugins to tell us:

• Disk space used per build and overall
• Compiler warnings graph with drill-down detail to individual line of code
• TODO graph with drill-down (captures any TODO, TODESIGN, FIXME comments in the code)
• JUnit graph (a built-in feature).

As an example, you can see JBoss' public Hudson here.

Answer 17

I'm a release engineer and I've used/written custom scripts, ant and maven. Maven is a difficult tool to grok and sell but I think it is worth it.

That Atlassian developer blog has a great series on how they switched to maven. Following that are my rational and ramblings about tools

From the Atlassian Developer's Blog: Maven in our Process - 4 part series

• Part 1
• Part 2
• Part 3
• Part 4

My Rantings

• Rolling your own: too much work and risk
• Ant: too much duplication
• Maven: nice decomposition, but hard to grok

Rolling my own from scratch using python and perl required way too much creation of functionality that's already delivered in by other people's tools and is fairly bullet proof. No need to solve copying or building zip files when ant or maven does it already.

Using ant is ok for a simple system but in larger systems I found I needed to use the same functionality over and over again. I tried to minimize this via clever use of antcall and including common ant xml files but project specific build.xml files. The problem is cut and paste vs the complexity of antcalls. Neither is great.

Maven offers the chance of decomposing the problem is building in a rather object oriented manner. I can break my build up into logical projects based to the components and how they interact. I can further extract commonality into maven plugins creating generic processors for common build tasks (provided they aren't already part of maven). This gives me a few benefits: I write less code, my developers have the logical view of the application presented to them in the build system, I can snap on various reporting and quality measures to improve the developer's experience.

The grok problem comes with the convention over configuration. This is baked into the maven philosophy and its great if you know the convention or have a tool to guide you. This is great and its annoying. If I don't know the convention, then I may wrestle with it and frustration will build. Frustration leads to anger and anger leads back to whatever tool you had before maven.

So, maven can be a real win, but someone needs to spend the time to figure out how the project will work with it and to document how folks will use it. I recommend thinking backward from the the user experience. If the new tool is a pain, people won't use it. If the experience is well crafted, you got a much better chance that they will.

Answer 18

One of my current dotnet projects uses CruiseControl.net for build scheduling and updates from source control. CC.Net calls Nant which has most of the build scripts. The Nant scripts then call the following tools depending on what we want the build to achieve:

SourceMonitor : Sourcecode-based stats. For example, rate of code change. Code complexity.

StlyeCop : Automated (source) checking of compliance against Microsoft Framework Guidelines.

FXCop : Binary analysis against Design Guidelines for class library designers, etc.

Wix : Generating MSIs for deployment to test systems and later to customers.

FIT : Testing deployed MSIs against user requirements.

Answer 19

I just recently needed to set up a buildserver, and found a recommendation for team city. I have to say it is extremely easy to get up and running, and I would recommend it, especially if you are using visual studio and nunit. Here are some further reading I used: http://blog.wekeroad.com/2008/01/27/source-control-and-continuous-integration-on-the-cheap/

Answer 20

I don't know about the Build System iteslf, but as for the runner - Team City, definitely. We just recently switched from CruiceControl.NET, and it's really all you want in a build system (I've already blogged about it here and here).

As for the build itself - as I said, I haven't experimented much with anything but MsBuild (which seem to work without problems). Just yesterday I had to write a custom build event for running FxCop on the entire solution, and it was a breeze.

Answer 21

Recently in my company we switched from QuickBuild to Zutubi Pulse.

QuickBuild is a decent tool but it misses any abilities to execute Unit Tests and parse their results. It is also pretty complicated to add non trivial logic with OGNL (I don't like it at all).

Pulse, on the the other hand, is what I always wished for.

• I supports all our other tools like Jira, Subversion, FishEye and Eclipse,
• It can parse various compilation and unit test output formats and represent them very nice.
• It's distributed and dependencies mechanisms are very good.
• Developers can execute CI build before any commit
• Developers can execute private (invisible) builds on all relevant platforms with one singe command.
• And probably on of the best - it has very simple built in scripting engine (XML) to define builds behavior.

Answer 22

Having used CruiseControl and CruiseControl.Net for 5+ years (and even tried build-o-matic), I'd say these are your best options:

For Java:

• TeamCity

For .Net:

• TeamCity

I've got it rolled out to the majority of my bank because:

• it's extreamly easy to set up.
• it very rarely goes wrong.
• The test failure feedback (developer time is expensive)
• You need less build machines (as they're more utilised) to provide a better service

And the last point means finally it's that bit easier to get the boss to buy monster build machines because developer time is precious. (did I repeat myself?)

I have not used Pulse and Hudson, and am not on the payroll of JetBrains. (Also NAnt is dead - use msbuild. NAnt people move with the times.)

Answer 23

.NET

We use UppercuT (which uses NAnt) and CruiseControl.NET

UppercuT bakes in a lot of conventions for building and makes it as easy as (1) solution name, (2) source control path, (3) company name for most projects!

http://code.google.com/p/uppercut/

Some good explanations here: UppercuT

Answer 24

I would recommend TeamCity or Hudson and Maven 2. Despite all the negative comments about Maven(I had a few problems myself but nothing that you can say it was a stopper) I still think it is the best build tool out there and combined with a CI like TeamCity(free bellow 20 build configurations) or Hudson it makes your job much easier.

Answer 25

.NET

We use Subversion + Draco .NET + Nant + WIX

Look here for Draco .NET

http://draconet.sourceforge.net/

Answer 26

At work we use TeamCity that runs FinalBuilder script and we use SVN for source control.

TeamCity can listen for source changes and run build & run unit tests and for complex scripts you can't go wrong using FinalBuilder, it has a great gui tool and has integration withzmany tools.