How and why do I set up a C# build machine?
I'm working with a small (4 person) development team on a C# project. I've proposed setting up a build machine which will do nightly builds and tests of the project, because I understand that this is a Good Thing. Trouble is, we don't have a whole lot of budget here, so I have to justify the expense to the powers that be. So I want to know:
I realize that this is a very large topic, and I'm just starting out. I couldn't find a duplicate of this question here, and if there's a book out there I should just get, please let me know.
EDIT: I finally got it to work! Hudson is completely fantastic, and FxCop is showing that some features we thought were implemented were actually incomplete. We also had to change the installer type from Old-And-Busted vdproj to New Hotness WiX.
Basically, for those who are paying attention, if you can run your build from the command line, then you can put it into hudson. Making the build run from the command line via MSBuild is a useful exercise in itself, because it forces your tools to be current.
Answer
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
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!