The CruiseControl.NET server can be configured to manage the integration requirements for several projects concurrently. To do this, simply include the configuration for the different projects consecutively in the ccnet.config file.

<cruisecontrol>
     <project name="project1">
          ...
     </project>
     <project name="project2">
          ...
     </project>
</cruisecontrol>

If you use the default values for Project working directories, artifact directories, State Managers and Xml Log Publishers, this should work for you straightaway, but if not, note the following conditions:

• Each project needs its own state file (see State Manager Blocks)
• Each project must save build logs to a separate directory (see Xml Log Publisher)
• Each project must have a separated build working directory (since builds are performed in parallel)
• Each project must have a trigger that specifies what will cause a build to occur (see Trigger Blocks)

Reducing Configuration Duplication

From CCNet 1.4 onwards, there is a Configuration PreProcessor, which allows to use variables and the like inside the ccnet config file. Look at the Pre Processorfor more information about this.

Before CCNet 1.4, the following technique is a solution.
As you add more projects to your ccnet.config file, you may end up with considerable duplication across configuration elements. This can make it a hassle to maintain your projects as you have to update the same settings in many places.

You can achieve some degree of reuse by using DTD entities. The example below demonstrates how you can create an entity to represent the cvs source control block so that it can be shared across two projects:

<!DOCTYPE cruisecontrol [
	<!ENTITY sc "<sourcecontrol type='cvs'>
		<executable>c:\cvs\cvs.exe</executable>
	</sourcecontrol>">
]>
<cruisecontrol>
	<project name="project1">
		&sc;
	</project>
	<project name="project2">
		&sc;
	</project>
</cruisecontrol>

Splitting the ccnet.config file

You can also use DTD entity notation to split your ccnet.config file into multiple smaller xml files. This can help you reduce duplication and can simplify the maintenance of certain configuration elements. The following example demonstrates how the configuration for two CCNet project project1 and project2 can be read in from separate files.

<!DOCTYPE cruisecontrol [
	<!ENTITY project1 SYSTEM "file:project1.xml">
	<!ENTITY project2 SYSTEM "file:project2.xml">
]>
<cruisecontrol>
  &project1;
  &project2;
</cruisecontrol>

The same approach should work at any level in the ccnet.config file. For example, email users and aliases can be managed in an external file:

<!DOCTYPE cruisecontrol [
	<!ENTITY email SYSTEM "file:email.xml">
]>
<cruisecontrol>
	<project name="project1">
		<publishers>
			&email;
			<xmllogger />
		</publishers>
	</project>
</cruisecontrol>

One limitation of this approach is that these external files will not be monitored by the CCNet server. Hence, CCNet will not automatically reload the configuration when these files change. The ccnet.config file will need to be touched for these files to be reloaded.