The problem for the latter argument is that A fails whenever B fails because there is no safety net for A.  As I was being overwhelmingly outnumbered, I caved in to the second suggestion which is to have A directly point to B‘s latest and greatest build.  Well, suffice it to say the decision came back to bite us.

We got bitten and yours truly had to spend additional time in fixing and changing the build scripts to adopt my original suggestion.  Now whenever B has a successful build, the script slaps on a label for A to point and consume.  This way we successfully ensure A will have the freshest dependency on B while avoiding unnecessary broken builds due to “tip” dependency.

Within the <triggers> block, you can add an additional trigger similar to this:

<projecttrigger serveruri=
“tcp://buildserver01:21234/CruiseManager.rem”
project=”Example Build 1.1″>
<triggerstatus>Success</triggerstatus>
<innertrigger type=”intervalTrigger”
seconds=”30″ buildcondition=”ForceBuild”>
</innertrigger>
</projecttrigger>

You can also have multiple triggers, one other trigger in this block might be the “modification set” trigger where it monitors the source control repository for changes to kickoff builds.

Inside the <remote services> code block, you can simply add allowForceBuild and allowStartStopBuild options:

<remoteservices>
      <servers>
         <server name="BUILDSERVER01"
         url="tcp://buildserver01:21234
         /CruiseManager.rem"
         allowForceBuild="false"
         allowStartStopBuild="false" />
      </servers>
</remoteservices>

By doing this, you would be able to have better control of the individual builds without any unwanted build trigger from developers, etc.

• 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.