SharpDeveloper
This article will tell you how to get a build process. It uses CruiseControl.NET to automate the build. You can use any other tool you like including a .BAT file, but CruiseControl will do just fine. It’s very easy to set up, it uses an XML configuration file and does most of the difficult job like connecting to your source control, applying labels, and getting your files to build for you.
1. Install CruiseControl.NET
This software is just great. Its totally free. Really it is a sophisticated batch file (.BAT file). It allows you to set up a build process fairly easily. It allows you to execute arbitrary processes and check the return codes and then report the results to your developers (or managers, or what not).
For example, you set it up to monitor your source control system (say SourceSafe or even a local folder in your file system) every 30 minutes, and then perform a build on it if there is changes.
It will report who made the last set of changes, what they did (check in, check out, delete, etc) by grabbing that information from your source control and also display the comment from the user that checked it in. It also labels it in the source control as UNVERIFIED (build process failed), or by incrementing the build number (again, this is configurable).
2. Install CCTray (its a little icon that sits in your tray and interfaces to the cruise control server to notify you when the build(s) are broken)
If the build does not compile (according to the procedure you set it up to run such as MsBuild, or Visual Studio, or executing some process) it will turn red and the team will all know that the build is broken and must be fixed. One person can volunteer to fix this build. Included with CruiseControl. Or you can just use the web dashboard instead:
3. Perform more advanced setup on it.
You can configure it to do just about anything. Our CruiseControl does a nightly build, runs NDOC (Alpha version, discontinued, you can use SandCastle instead if you like) to get the latest documentation, and also we have a separate project that runs some database unit tests against 5 or 6 QA databases. The NDoc step is a bit tricky if you are running a “Web Site Project” because by default the “Web Site Project” does not create XML documentation files when compiled and requires modifications to your Web.Config. Getting NUnit to run requires some advanced setup, because NUnit requires you to have a copy of the Web.Config in the local folder where the tests are run. You can also run a bunch of fun stuff like Simian (Similarity Analysis, Duplicate Line counter), Fitnesses (another testing framework), NCover (Unit test coverage), etc.. It can also send out emails on each successful build if you like (technically it can do cartwheels if you have an exe file that you can make it call to do the cartwheels 
)
)4. Involve QA and the rest of the team to start using the build numbers and relying on CruiseControl to verify the site compiles. Also you can start to add more unit tests to your code and strengthening the quality of your product, and then using NCover to verify how much of your site is tested. Not to mention you can also stick FxCop in there! FxCop will analyse your code according to Microsoft Best Standards and create a report for you on bad code that is not according to their naming conventions, or bad code that is not using SQL Parameters (and could have SQL Injection vulnerabilities)
More to come soon. In summary – CruiseControl makes a world of difference. Get it now.
As Jeff Atwood wrote, "The F5 key is not a build process"
Related Reading:
Other Interesting Posts
If you enjoyed this article, please consider sharing it!
