Question

I find that I am always tuning and tweaking our CI setup as we add new projects. While there is NO question that the benefits are awesome for existing code that seldom changes, new projects or volitile ones seem to require more work as I have to configure each project to be “intergrated” as well as maintain an ever-growing CCNET.config file. Is there a better strategy short of building an utility to manage adding and modifying a CI setup?

Answer 1

I do a few things to try keep it under control:

1) Split the config file into two. I have one file that mostly stays the same and contains a set of constants e.g.

<?xml version="1.0" encoding="utf-8"?>
<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
  <!-- Constant definition used by the projecct config to prevent changes being required for each iteration -->
  <cb:define branch="branch name for source control"/>
  <cb:define ciserver="Server name in here"/>
  <cb:define devenv="Path to DEVENV"/>
  <cb:define nunit="Path to NUNIT"/>
  <cb:define cruisecontrol="Cruisecontrol Path"/>

  <!-- Include file to the standard CI project definitions. This file is kept under source control -->
  <cb:include href="config\CCProjects.config"/>
</cruisecontrol>

The use of constants allows you to make a single change and have it propagate through each task in the config file.

See docs

2) Keep the file with the projects in under source control. The project file gets updated as part of the SVN checkout. This helps track changes that get made and let you rollback without too much hassle.

Maybe it has got to the point where CC.Net is working against you rather than for you. I’ve heard good things about the ease of configuration of other CI servers, like Hudson, but it may not be a good fit with your build environment.