Where to start with CruiseControl.NET

Question

I'm setting up my team's source control + build/integration process from scratch. We were using VSS and a tool we created in-house to perform the build process. We decided to move on to a more modern environment. I have the SVN running, and I would like to set a continuous integration process with CruiseControl.NET. Is there a good step-by-step starter guide that will get me started with the best practices of this tool?

Answer 1

Really, the documentation is pretty solid

Answer 2

Before leveraging CruiseControl to it's fullest extent, you need to create an automated build script that can be run by msbuild or nant. After you get your project building in one step, then you can start integrating CruiseControl into the mix. Here are some resources to help get you started:

• CruiseControl.net Wiki - A very good resource.
• CruiseControl.net SourceControl Block - Shows how to use svn with CruiseControl.net with the sourcecontrol block
• Getting CruiseControl.net, MsBuild, and SVN setup - A resource stepping you through the steps to get everything meshing together.

Answer 3

Here are some links that might be useful:

http://www.codeproject.com/KB/dotnet/cruisecontrol_continuous.aspx

http://devlicio.us/blogs/ziemowit_skowronski/archive/2007/03/10/continuous-integration-1-the-environment-and-the-first-build.aspx

http://code.google.com/p/ci-factory/

Cheers John

Answer 4

See Dale's answer or you could pay me to show you? just a thought ;)

Answer 5

An excellent resource I've found for CI recently is by Martin Fowler, author of the famous "Enterprise Application Architecture" book.

URL: http://martinfowler.com/articles/continuousIntegration.html

Answer 6

One tip we have learned - if you have a reasonably large team and the product you're referring to is some "push to QA so people can test" type of scenario, resist the urge to have it build every single time someone checks something in. It will likely take down QA for some amount of time and cause QA to be disrupted a lot before you figure out that people are checking stuff in all day long.

For a "push to QA" scenario, just have it go off every evening if it detects changes.

For a "see if it builds" scenario, once every hour is good (again, people check in stuff way too often on a decent sized team to make instant builds worthwhile)

Answer 7

If you're looking a .NET CI could I suggest you have a look at Team City. I think it's better and it is free for up to 20 users.