My first attempt was this:

<schedule interval="900">
    <ant time="1200"
	 anthome="${ANTHOME}"
	 antworkingdir="${my_build.dir}"
	 buildfile="${my_build.file}" 
	 target="build.all.then.test" 
	 uselogger="true"
	 usedebug="false"/>		
    <ant time="1800" 
	 anthome="${ANTHOME}"
	 antworkingdir="${my_build.dir}"
	 buildfile="${my_build.file}" 
	 target="build.all" 
	 uselogger="true"
	 usedebug="false"/>	
    <ant time="2400" 
	 anthome="${ANTHOME}"
	 antworkingdir="${my_build.dir}"
	 buildfile="${my_build.file}" 
	 target="build.all" 
	 uselogger="true"
	 usedebug="false"/>			 
</schedule>

Which translates to the following build frequency: 6pm and midnight just build using build.all target. Noon build using build.all.then.test target.

It would make sense right? That didn’t work. For some strange reasons, all three time frame, it built using build.all.

So then I modified it, according to CruiseControl’s documentation recommendation, to the following:

<schedule interval="900">
    <ant time="1200"
	 anthome="${ANTHOME}"
	 antworkingdir="${my_build.dir}"
	 buildfile="${my_build.file}" 
	 target="build.all.then.test" 
	 uselogger="true"
	 usedebug="false"/>		
    <ant multiple="1" 
	 anthome="${ANTHOME}"
	 antworkingdir="${my_build.dir}"
	 buildfile="${my_build.file}" 
	 target="build.all" 
	 uselogger="true"
	 usedebug="false"/>			 
</schedule>

Which translates to check for changes and build every 15mins, but for the 12pm build, run the build.all.then.test instead. That did NOT work.. Did you run into a similar problem? What was your solution?

With the suggestion and help from a colleague in SQA, a Visual Basic executable wrapper was written on top of the QTP.exe program and viola!, NAnt now detects the proper exit codes and stops flinging build ‘poo’ errors onto the reports.  First you must use DOS cmd files to detect the various negative exit codes Quick Test Professional spits out whenever it finishes, then write those codes down based on successful/failed test runs for use with your Visual Basic wrapper.  Why Visual Basic?  Because its simple and straight forward, you can also use PERL or any other wrapper that tickles your fancy.

Now.. the real problem arises when you want to integrate QTP test reports into CruiseControl.NET’s webdashboard without having to actually open Quick Test Professional program suite itself.  I will elaborate on how I get around that in a future blog post.

• Engineering: These builds lives on the individual developer’s machine. It should never see the light of day beyond this scope. This is merely a convenient build tool designed to allow developers to easily build and debug their code. There are exceptions, however; for teams developing in the new .NET paradigm using the all inclusive solution (*.sln) files to build will have no need for this type of build. This is mainly useful for older softwares where several manual modification/moving/copying of file operations are need. These builds are then classified as on-demand.
• Continuous Integration (Development): These types of builds can also be referred to as the Continuous Integration (CI) builds. These builds lives on a stand-alone machine and the artifacts should only be made available to the immediate development team of the respective project. These builds should then be considered continuous since it is constantly polling for new check-ins.
• Software Configuration Management (Product Testing): These builds are on-demand and should only be initiated by team leads or managers of the particular development group. These builds should be built based on a label within the source control tool. There should not be any errors as these builds are derived from successful CI builds. The consumer for these builds will be the QA group.
• Software Configuration Management (Product Release): Similar to that of the product test SCM builds, these only differ in nature and title as they are meant for real world consumption.

To create quick build turn-arounds, plentiful CPU cycles, clean and reproducible build environments; each one of these build classifications should live on its own machine/server.   The two flavors of SCM builds can actually be on the same server, but Engineering, CI, and SCM must all exist separately.

There is another way of looking at this, especially when considering the agile process, and especially when in an enterprise software environment.

You still have the needs for a Engineer build and a CI build but instead of the SCM builds you instead “promote” the CI build.  What this effectively means is that someone chooses a CI build to push towards QA, and then this is pushed ultimately to production, etc.

As a process it has the advantage of being simplier and centralises all efforts around the automated build.   It is physically impossible for the wrong code to get built for production because someone changed a tag, instead the built artifact is the same (and can be checked against an MD5 to test it).

Although not as frequent in the .NET world its a common practice in the Java world.