Improving Your Build Process

Question

Or, actually establishing a build process when there isn\'t much of one in place to begin with.

Currently, that\'s pretty much the situation my group faces. We do web-a

Answer 1

I've only worked on a couple of .Net projects (I've done mostly Java) but one thing I would recommend is using a tool like NAnt. I have a real problem with coupling my build to the IDE, it ends up making it a real pain to set up build servers down the road since you have to go do a full VS install on any box that you want to build from in the future.

That being said, any automated build is better than no automated build.

Answer 2

Our build system is a makefile (or two). It has been rather fun getting it working as it needs to run on both windows (as a build task under VS) and under Linux (as a normal "make bla" task). The really fun thing is that the build gets the actual file list from a .csproj file, builds (another) makefile from that, and run that. In the processes the make file actually calls it's self.

If that thought doesn't scare the reader, then (either they are crazy or) they can probably get make + "your favorite string mangler" to work for them.

Answer 3

I have a set of Powershell scripts that do all of this for me.

Script 1: Build - this one is simple, it is mostly handled by a call to msbuild, and also it creates my database scripts.

Script 2: Package - This one takes various arguments to package a release for various environments, such as test, and subsets of the production environment, which consists of many machines.

Script 3: Deploy - This is run on each individual machine from within the folder created by the Package script (the Deploy script is copied in as a part of packaging)

From the deploy script, I do sanity checks on things like the machine name so things don't accidentally get deployed to the wrong place.

For web.config files, I use the

<appSettings file="Local.config">

feature to have overrides that are already on the production machines, and they are read-only so they don't accidentally get written over. The Local.config files are not checked in, and I don't have to do any file switching at build time.

[Edit] The equivalent of appSettings file= for a config section is configSource="Local.config"

Answer 4

One thing I would suggest ensure your build script (and installer project, if relevant in your case) is in source control. I tend to have a very simple script that just checks out\gets latest the "main" build script then launches it.

I say this b/c I see teams just running the latest version of the build script on the server but either never putting it in source control or when they do they only check it in on a random basis. If you make the build process to "get" from source control it will force you to keep the latest and greatest build script in there.

Answer 5

We switched from using a perl script to MSBuild two years ago and haven't looked back. Building visual studio solutions can be done by just specifying them in the main xml file.

For anything more complicated (getting your source code, executing unit tests, building install packages, deploying web sites) you can just create a new class in .net deriving from Task that overrides the Execute function, and then reference this from your build xml file.

There is a pretty good introduction here: introduction

Answer 6

We use UppercuT. UppercuT uses NAnt to build and it is extremely easy to use.

http://code.google.com/p/uppercut/

Some good explanations here: UppercuT