Cruise Control .NET

Our development team has finally decided that each of us individually pressing 'F5' in Visual Studio is no longer an effective build system.  Another dev group in the building took up Cruise Control.NET and Octopus at the end of last year.  I've starting investigating its potential for our team as well.

So a quick rundown of our current situation:

• We are actively developing and supporting a web application that allows users to login and complete work from IE 8+ browsers.  We are currently doing work to support both Firefox and Chrome as well, so there is ongoing testing as we develop new features.
• Our main application uses a viewer that requires an ActiveX install on IE version 8, but uses an HTML5 canvas object for the viewer on IE9+.  
• One member of the team has developed a central user authentication page that is driven by customized JQuery grids.  It's complex and its integration into our main application has been bumpy.  The idea was single sign on, but it isn't quite there.
• Data is made ready for user consumption by a Windows Service that runs on various virtual machines and writes to a set of project-specific databases.  We receive some data by web service, a replication process from another set of databases, or even flat-file.  It's a moderately flexible, but aging service application.
• We have been using SVN for source control for the last couple of years.  There are still those on the team that struggle to use it within the standards that I developed for our group, but we're getting there.
• We've just begun to use NuGet Package Manager for a number of dll's and there is some confusion in our team about which package files are appropriate to be checked into source control.

We have a few goals in making this change to our build processes.  First, we want a simple and repeatable build process that is scripted.  We have individuals on the team that have built various pre and post build scripts into their local machines and it creates issues when source files get checked into the repository. 

Second, we have a new hire whose specific charge is developing a suite of automated tests for our application.  He is making progress and we would like to integrate his smoke tests into the build process.  Once a build command is sent, we want to kick off his set of tests and return a pass/fail for each of them.

Third, we want to approach our development task list with confidence.  If the source is continuously being built and tested, we should be able to refactor existing code and develop new features with the knowledge that we are working off a solid code base.  I'd like to get us to a world where a developer's commit to the SVN trunk automatically kicks off a build process and gives us immediate feedback.  

Cruise Control seems like a good solution. The challenges that I foresee based on my research would be as follows:

• Setup cost.  The configuration and scripted build will take time and effort to create.
• Our current application is built in a way that requires fairly brittle testing in order for it to be worthwhile.  
• We do not currently have a set of scripts that will create a development environment from scratch.  Getting a new hire up to speed is time consuming.
• And of course the reluctance of the team to make a change to our current process.  It's slow and painful, but it's known and we make it work.

I've installed Cruise Control v.1.8.3 on my local machine.  There are some permission issues to resolve, but it was relatively painless to setup.  Next steps are to associate this with a local project to test out some of its features.