Blog For .NET

I started using continous integration about five years ago with Cruise Control.net aka CCNet and NAnt. Recently I had to build a new continous integration solution from scratch. After some preliminary investigation I decided to use Cruise Control.net and MS Build. While there are some other excellent products out there for managing builds and unit tests, our needs were lite and I wanted to stay as close I could to the Microsoft ecosystem to avoid larger infrastructure changes. Building a continous integration server was a bit of a leap for other team members and my needs were relatively simple. Every company’s build process varies a bit, but since my needs were basic enough and my solution used out of the box tools, I hope someone else can save a few minutes by starting a few steps ahead.

The build server setup was simple – one build per project per environment. Each build performs the following actions:

1. get the latest copy of code from source control (subversion)
2. build the code
3. update the web.config file to target the deployment environment
4. if configured to, run aspnet_compile and aspnet_merge
5. deploy the code to the target server

A few notes about using Cruise Control.Net and MS Build.

• When a configuration file changes, you need to stop and start the CCNet service (not the web application, but the service)
• Because the CCNet configuration for each build can be a bit verbose, I moved the builds for each project into their own configuration files:
  <!DOCTYPE cruisecontrol [
  <!ENTITY Project1 SYSTEM "ProjectConfigs\Project1.config">
  <!ENTITY Project1 SYSTEM "ProjectConfigs\Project2.config">
  ...
  ]>
  <cruisecontrol>
  &Project1;
  &Project1;
  …
  </cruisecontrol>
  and then within each client project, have a build for each environment
  <project name=”Project1 Development Environment”>
  …
  </project>
  <project name=”Project1 Testing Environment”>
  …
  </project>
• MS Build is a programming language. Before you start coding something custom to your needs, see if something else already does it, particularly the MS Build documentation or the MS Build Community Tasks. Much of the documentation isn’t the best but the libraries are quite powerful
• When calling MS Build from CCNet, via the ms build task, CCNet will automatically define additional variables for you like the “working directory”.
• Plan ahead of time how you want to manage configuration files for deployment. VS2K10 and MS Build 4.0 have a lot more options for generating configs. The two standard approaches are to either generate a new configuration file via xslt or to set the ConfigSource attribute of the configuration section to an environment specific file (http://msdn.microsoft.com/en-us/library/system.configuration.sectioninformation.configsource.aspx) – in the build file I created, I use the latter method partly because we’re using VS2K8 and partly because I feel it’s easier to manage.
• the CCNet service needs to run under an account with permissions to deploy the code. If the deployment pushes the code to another machine, the CCNet service should run under a domain account with permissions there.
• when CCNet goes to the source control server (svn in my case) it needs credentials to authenticate. Either specify these credentials in the config or open a command prompt under the account that the CCNet service runs under and do an svn update. After entering your credentials there, they will be cachedso they don’t need to be specified in clear text in the config.

To use the sample, install CCNet, and unzip the sample file to the “server” directory – usually: c:\Program Files\CruiseControl.NET\server

The sample contains three files:

• ccnet.config – the file that tells CCNet what the builds are
• Project1.config – the file that defines the builds for Project1 and sets the project/environment specific variables for each build
• Main.msbuild – the MS Build file that builds the code, updates the configs, and deploys everything

The sample can be found here

No Comments yet »