What does CruiseControl do?

Question

What does CruiseControl actually do? i cant understand it. What do i use it for? someone said to me it keeps track of your build dates and if it is a success or error but really why do i need that? I'll assume it can email you if there is a build error but outside of that (assuming its long and i do nightly or evening builds) is there anything i can use it for? as a hobbyist or on a small project with <=5 ppl?

Answer 1

The advantages of continuous build systems are most commonly extolled for multi-developer projects, but they do have some advantages for smaller teams or sole developers.

First lets look at the typical use case: A large project with lots of committers. It's possible that sometimes, the build will be broken. Maybe someone's local environment doesn't match up with the server and they commit code that only compiles on their machine, or someone doesn't check their code compiles because they're in a hurry, or someone's checkout is not up to date when they edit and commit.

Either way, the build is now broken. The bug needs to be fixed, but it's possible it won't be clear who actually caused it, and time is of the essence! As people update to the head, they will no longer have code that compiles, making it harder for them to do work.

Monitoring the status of the build can help avoid many of these events occurring. As soon as the offending code goes into the repo, the build will fail, but they will know immediately so people won't check it out. As it's the current head, it's easier to just revert. Even if people do end up with that code, at least they know who caused it, and which commit it was.

It may even (depending on the speed of the build) be possible to have build checking as a pre-commit hook, stopping bad code ever getting into the central codebase in the first place.

So what does it give smaller teams or lone developers?

Well, it might still be handy to know if the build breaks, depending on what your work practices are like with writing and testing code. In small teams, if there was geographical separation in particular, I can see it being useful to know the build is broken and who when and what broke it.

There are other things you could use it for. If you have it set up, then you have a server that always has a copy of the latest build on it. If the server was web facing, you now have an easy way for people to try out the latest version of your software (e.g. Firefox nightlies and things like that). People outside your project may also be interested in whether the code builds on their platform, or if it passes particular tests.

Finally, take a look at the CI dashboard for Chromium for an idea of what sort of information you can get. We can see the build status on each platform, the commits and what effect they had on that, code coverage statistics, download latest builds, and for a build that failed we can see which test it failed and what the error message was. Pretty cool!

Answer 2

The usual use case for CruiseControl (and other Continous Build [CI] Systems like Hudson, Anthill, ...) is to check query central source code management system (SCM) regularly (every minute?) or get informed by the repo if there are changes. The CI then should build the code.

In addition to that it is possible to run tests, deploy artifacts (e.g. to a maven repo or a demo server) on each build. You may have multiple builds, for example one that will be triggered by each change in your SCM and one that will be triggered each night an in the lunch break. The "real" CI build will just compile the code and run unit tests while the "big" build may run integration tests and other tasks that take a lot of time.

IMHO a benefit of a CI system is to have at least one building environment that differs from the development machines. For example the environment can be modified to mimic the environment of your customers. Another nice feature is the notification about build failures AS THEY HAPPEN. That way it's easier to figure out when makes the builds break and how to fix it.

You may also configure builds on the CI machine that are to be rune manually an that automate the rollout process (if your application and customers allow this). Or have a build that creates an executable for non-developers who need to generate snapshot versions of your app to test them.

A CI system is quite versatile and is's a good thing to have it even in small teams. A hobbyist might not need such a tool, but if there are at least 2 developers involved it's a good thing to have CI!