Continuous integration tools with “pipeline” support?

Question

Our automated builds and tests are taking an increasing amount of resources, especially since we support many platforms and test in both debug and optimized. So, I'm looking for some tool support that would allow a more incremental "pipeline" approach so we could get feedback and results faster. Some ideal characteristics would include:

1. Support for incremental feedback so we can see the results of the build, unit tests, fast tests, longer running tests, static analysis, etc. as they become available.

2. Task dependency: if the build fails, then tests shouldn't be run but other tasks could be (like lint or something).

3. Support for multiple build and test tools (including custom).

4. Support for multiple platforms (Linux, Mac, possibly Windows).

5. Some archiving ability would be great, things like log files, build/test output, etc. Natrually, this can get unmanageably large so some data would ideally be purged after X many days or Y many builds.

Any pointers or personal advice is greatly appreciated.

Answer 1

You might want to take a look at Jenkins (formerly Hudson).

Answer 2

I've been using Anthill but you have to pay for it.

Answer 3

Automated Build Studio comes close I think, though it probably isn't an option for you because of its windows-only nature.

1. Yes. The web front-end provides incremental feedback as builds are running, both in detail, and as a percentage.
2. Yes. The build process is a hierarchy of tasks. You can determine whether a task is fail-continue or fail-abort.
3. Yes. Tasks can be pretty much anything. The toolbox of tasks that accompanies it is pretty complete.
4. No. The build server must be a windows machine. You can however start builds from the web front-end.
5. Yes. Every build is logged in detail, hierarchically, so it's easy to pin-point what happened at every step.

Answer 4

I think buildbot will do everything that you want:

1. Web front end displays output from commands.
2. Full task dependencies
3. Fully custom tools - python scripting, but mostly shell scripts
4. Current we're using it on Linux, Mac, Solaris, HP-UX
5. It records everything, I don't know how/if it purges things.

Answer 5

Would have to agree on the thoughtworks option - Go "Agile Release Management" http://www.thoughtworks-studios.com/go-agile-release-management

There's a community edition (free) and some good features in the enterprise edition such as environment configurations and deployment of specific artifact (versions) to specific environments.

Answer 6

My JetBrains TeamCity setup approximates what you need.

Under a single project, I've set up multiple different build configurations.

The difference between each build configuration is in the choice of build targets (I use NAnt) and in triggering.

I have an "XYZ Integration" configuration which does a debug build and runs some NUnit tests. This triggers 60 seconds after a checkin completes, giving quick feedback to the development team.

I also have an "XYZ Daily" configuration which does a debug build, runs NUnit tests, then builds some MSIs and compiles some documentation. As you can probably guess, this runs once a day.

You could do the same, but with a wider range of configurations.

Answer 7

We use Hericus Software's Zed Builds and Bugs Management and it can handle what you are describing. Our main builds consist of over 61 discrete steps covering compiles for Java, C++, C#, and installation builds for 5 different OS platforms. Some of the steps execute in parallel, some can fail without causing the whole build to fail, and many of the steps are executed remotely on different machines.

1) Yes. As the steps are executed for a build you can immediately see the results of the step without having to wait for the whole build to complete.

2) Yes. You can define whether a step failure causes a complete build failure or not. The ability to create "child" or "sub" builds called by a "parent" or "master" build allows for extreme flexibility.

3) Yes. We're using makefiles, ant, C# solutions, and several custom scripts and they all integrate well.

4) Yes. The build server is java and only requires a 1.6 JDK, so any platforms work for either the main build server or the satellite build servers.

5) Yes. Everything copied into the build "status" directory is saved. This includes command standard output/error which can be reviewed from the web site. You choose how much "dev" build history to keep in terms of number of builds. A build can also be promoted to "QA" in which case it won't be deleted until it has been removed from "QA". From QA you can promote a build to "Production" which will keep all of the build artifacts until you decide to delete them.

Answer 8

plese try Cruise from Thoughtworks