We have a large collection of nAnt scripts that build our various products. They almost all have the following structure:
- Erase old working copy.
- Check out complete fresh copy from version control.
- Increment build number in appropriate file (custom nAnt task).
- Run static analysis (StyleCop, Perl scripts)
- Build solution using Visual Studio – ends up with MSI output.
- Run unit tests (nUnit, JSUnit)
- Run static analysis (FxCop)
- Zip up deliverables (MSI, readme, etc) into well-named package.
- Put this zip package onto a server share.
- Email results to team.
From our research, it 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?
Best Answer
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.