How and why do I set up a C# build machine? [closed]

Answer 1

We've had great luck with the following combo:

1. Visual Studio (specifically, using the MSBuild.exe command line tool and passing it our solution files. removes the need for msbuild scripts)
2. NAnt (like the XML syntax/task library better than MSBuild. Also has options for P4 src control operations)
3. CruiseControl.net - built in web dashboard for monitoring/starting builds.

CCNet has built in notifiers to send emails when builds succeed/fail

On justification: This takes the load off developers doing manual builds and does a lot to take human error out of the equation. It is very hard to quantify this effect, but once you do it you will never go back. Having a repeatable process to build and release software is paramount. I'm sure you've been places where they build the software by hand and it gets out in the wild, only to have your build guy say "Oops, I must have forgotten to include that new DLL!"

On hardware: as powerful as you can get. More power/memory = faster build times. If you can afford it you'll never regret getting a top-notch build machine, no matter how small the group.

On space: Helps to have plenty of hard disk space. You can craft your NAnt scripts to delete intermediate files every time a build starts, so the real issue is keeping log histories and old application installers. We have software that monitors disk space and sends alerts. Then we clean up the drive manually. Usually needs to be done every 3-4 months.

On build notifications: This is built in to CCNet, but if you are going to add automated testing as an additional step then build this into the project from the get-go. It is extremely hard to back fit tests once a project gets large. There is tons of info on test frameworks out there (probably a ton of info on SO as well), so I'll defer on naming any specific tools.

Answer 2

Update: Jenkins is the most up to date version of Hudson. Everyone should be using Jenkins now. I'll be updating the links accordingly.

Hudson is free and extremely easy to configure and will easily run on a VM.

Partly from an old post of mine:

We use it to

• Deploy Windows services
• Deploy web services
• Run MSTests & display as much information as any junit tests
• Keep track of low,med,high tasks
• trendgraph warnings and errors

Here are some of the built in .net stuff that Hudson supports

• MSBuild
• NAnt
• MSTest
• Nunit
• Team Foundation Server
• fxcop
• stylecop
• compiler warnings
• code tasks

Also, god forbid you are using visual source safe, it supports that as well. I'd recommend you take a look at Redsolo's article on building .net projects using Hudson

Your questions

• Q: What kind of tools/licenses will I need? Right now, we use Visual Studio and Smart Assembly to build, and Perforce for source control. Will I need something else, or is there an equivalent of a cron job for running automated scripts?

• A: I just installed visual studio on a fresh copy of a VM running a fresh, patched, install of a windows server OS. So you'd need the licenses to handle that. Hudson will install itself as a windows service and run on port 8080 and you will configure how often you want it to scan your code repository for updated code, or you can tell it to build at a certain time. All configurable through the browser.

• Q: What, exactly, will this get me, other than an indication of a broken build? Should I set up test projects in this solution (sln file) that will be run by these scripts, so I can have particular functions tested? We have, at the moment, two such tests, because we haven't had the time (or frankly, the experience) to make good unit tests.

  A: You will get an email on the first time a build fails, or becomes unstable. A build is unstable if a unit test fails or it can be marked unstable through any number of criteria that you set. When a unit test or build fails you will be emailed and it will tell you where, why and how it failed. With my configuration, we get:

  • list of all commits since the last working build
  • commit notes of those commits
  • list of files changed in the commits
  • console output from the build itself, showing the error or test failure

• Q: What kind of hardware will I need for this?

  A: A VM will suffice

• Q: Once a build has been finished and tested, is it a common practice to put that build up on an ftp site or have some other way for internal access? The idea is that this machine makes the build, and we all go to it, but can make debug builds if we have to.

  A: Hudson can do whatever you want with it, that includes ID'ing it via the md5 hash, uploading it, copying it, archiving it, etc. It does this automatically and provides you with a long running history of build artifacts.

• Q: How often should we make this kind of build?

  A: We have ours poll SVN every hour, looking for code changes, then running a build. Nightly is ok, but somewhat worthless IMO since what you've worked on yesterday wont be fresh in your mind in the morning when you get in.

• Q: How is space managed? If we make nightly builds, should we keep around all the old builds, or start to ditch them after about a week or so?

  A: Thats up to you, after so long I move our build artifacts to long term storage or delete them, but all the data which is stored in text files / xml files I keep around, this lets me store the changelog, trend graphs, etc on the server with verrrry little space consumed. Also you can set Hudson up to only keep artifacts from a trailing # of builds

• Q: Is there anything else I'm not seeing here?

  A: No, Go get Hudson right now, you wont be disappointed!

Answer 3

How? Have a look at Carel Lotz's blog.

Why? There are several reasons that I can think of:

• A working build, when properly implemented, means that all your developers can build on their machine when the build is green
• A working build, when properly implemented, means that you are ready to deploy at any time
• A working build, when properly implemented, means that whatever you release has made a trip to your source control system.
• A working build, when properly implemented, means that you integrate early and often, reducing your integration risk.

Martin Fowler's article on Continuous Integration remains the definitive text. Have a look at it!

Answer 4

The main argument in favour is that it will cut the cost of your development process, by alerting you as soon as possible that you have a broken build or failing tests.

The problem of integrating the work of multiple developers is the main danger of growing a team. The larger the team gets, the harder it is to coordinate their work and stop them messing with each other's changes. The only good solution is to tell them to "integrate early and often", by checking in small units of work (sometimes called "stories") as they are completed.

You should make the build machine rebuild EVERY time some checks in, throughout the day. With Cruise Control, you can get an icon on your task bar that turns red (and even talks to you!) when the build is broken.

You should then do a nightly full clean build where the source version is labeled (given a unique build number) that you can choose to publish to your stakeholders (product managers, QA people). This is so that when a bug is reported, it is against a known build number (that's extremely important).

Ideally you should have an internal site where builds can be downloaded, and have a button you can click to publish the previous nightly build.

Answer 5

It is all about the health of the build. What this gets you is that you can set up any type of things you want to happen with the builds. Among these you can run tests, static analysis, and profiler. Problems are dealt with much much faster, when you recently worked on that part of the application. If you commit small changes, then it almost tells you where you broke it :)

This of course assumes, you set it up to build with every check in (continuous integration).

It also can help get QA and Dev closer. As you can set up functional tests to run with it, along with profiler and anything else that improves feedback to the dev team. This doesn't mean the functional tests run with every check in (can take a while), but you set up builds/tests with tools that are common to the whole team. I have been automating smoke tests, so in my case we collaborate even more closely.

Answer 6

Just trying to build a bit on what mjmarsh said, since he laid a great foundation...

• Visual Studio. MSBuild works fine.
• NAnt.
• NantContrib. This will provide additional tasks such as Perforce operations.
• CruiseControl.net. This is again basically your "build dashboard".

All of the above (save for VS) is open source, so you're not looking at any additional licensing.

As Earwicker mentioned, build early, build often. Knowing something broke, and you can produce a deliverable is useful for catching stuff early on.

NAnt includes tasks for nunit/nunit2 as well, so you can actually automate your unit testing. You can then apply stylesheets to the results, and with the help of the framework provided by CruiseControl.net, have nice readable, printable unit test results for every build.

The same applies to the ndoc task. Have your documentation produced and available, for every build.

You can even use the exec task to execute other commands, for instance, producing a Windows Installer using InstallShield.

---

The idea is to automate the build as much as possible, because human beings make mistakes. Time spent up front is time saved down the road. People aren't having to babysit the build by going through the build process. Identify all the steps of your build, create NAnt scripts for each task, and build your NAnt scripts one by one until you've wholly automated your entire build process. It also then puts all of your builds in one place, which is good for comparison purposes. Something break in Build 426 that worked fine in Build 380? Well, there are the deliverables ready for testing -- grab them and test away.