As a follow-on to the last post Self-Monitoring Build System, I figured I’d discuss the way I manage my projects and their dependencies. I believe it’s important to have a self-contained project that allows “time to login screen” to remain as small as possible. I do this by packaging the source, libraries, tools, basically everything under a single space within the SCM. This puts the control and responsibility for managing dependencies where I feel it should be; in the IDE so that, ultimately, it’s in the developer’s hands rather than in the SCM itself. Plus, it makes sure that the build server will always have what it needs to build the project without needed extra installs. If you keep the build server clean, you won’t be in a pinch should it take a dirt nap. (You ARE using VMs for your build servers aren’t you??) Keep in mind that when I’m saying “project”, I’m referring to a project in the sense of a product or system in the enterprise which is probably comprised of at least 1 Visual Studio solution and a few ancillary things.
In an effort to keep things practical and concrete, here’s how I usually set things up. To start with I have a common project which contains a basic “template” build script and the tools that I like to use – NCover, NUnit, MbUnit, NAnt, ILMerge, Simian, etc. Now, all subsequent projects will be branched from this common project. This allows you to manage which version of the tools each project is running as well as easing the push to move a project to the latest and the places you have to check in that new version. Side note: There has been a recent discussion on the altdotnet group regarding svn setup and it has been interesting to see the discussion. However, this configuration assumes that you’re using a single repository because…well…that’s the only way I’ve worked thus far. If you’ve got an idea on how to make it work with multiples, I’d like to hear about it.
David O’Hara is a Senior Consultant with Improving Enterprises in Dallas, Texas.