What does CruiseControl (or any other CI tool) give more than well-written (n)Ant?

We have a large collection of nAnt scripts that build our various products. They almost all have the following structure:

1. Erase old working copy.
2. Check out complete fresh copy from version control.
3. Increment build number in appropriate file (custom nAnt task).
4. Run static analysis (StyleCop, Perl scripts)
5. Build solution using Visual Studio - ends up with MSI output.
6. Run unit tests (nUnit, JSUnit)
7. Run static analysis (FxCop)
8. Zip up deliverables (MSI, readme, etc) into well-named package.
9. Put this zip package onto a server share.
10. Email results to team.

From our research, it开发者_Python百科 seems that CruiseControl(.net?)/Hudson/BuildBot would only add the trigger that causes the build, which at the moment is double-clicking the nAnt script over Remote Desktop and a status dashboard.

Are we missing anything else significant?

The question is subjective, and thus so is my answer.

In the projects I've automated before, CruiseControl was used essentially for that one purpose: so we didn't have to remote into the build machine and trigger builds. The CI part is that CruiseControl will monitor the repository for you, triggering builds at the intervals you define.

It also gave us the dashboard from which could trigger releases, or go back to examine logs and artefacts from past builds.

For us that was enough benefit to implement CruiseControl. Perhaps it doesn't "seem" like much until you've finished it and a month later realized you haven't had to touch your build system because it's off silently and thanklessly doing its thing for you.

A Continuous Integration server such as Hudson would do 1, 2, 3, 9 and 10 for you so that you don't have to implement them yourself. If you've already got it working that's maybe not a huge improvement for your current project but it makes things simpler for subsequent projects. It would also, as you mention, take care of when to trigger the build.

Hudson will also chart various trends over time, such as test coverage, build time, static analysis results. You can also have more sophisticated notifications than just e-mail if you choose.

The most important thing it gives you is visual feedback (the bigger the screen is better). When you have one machine, dedicated to displaying buildresults, visible to all team members, it works like a catalyst to people see that something is wrong and fixes it.

If you have something like that standing in a place where your boss can see it and ask you "Hey Wilkinson, why is this screen red?" will you fix your build faster?

Thay all look the same, you can pick whatever you think fits your needs, just have one setup and running.