Q & A from Build and Deploy with NAnt in Rockville

I presented on "Build and Deploy with NAnt" (slides/code available) at the WinProTeam Rockville .NET User Group on 11/4.

The following are some of the questions (and my answers) from the event:

• Can NAnt be used to compile projects in any .NET language? (particularly C++ projects)

The <solution> task in NAnt appears to definitely support both C# and VB.NET project.  John Lam has posted about compiling C++ with NAnt here and here. 

Tracing the source code for the <solution> task in NAnt.VSNet.ProjectFactory (which appears to control the derived ProjectBase class that actually does the compilation) shows that only C#, VB.NET and C++ projects are currently supported.

if (projectExt == ".vbproj" || projectExt == ".csproj") 
{
 Project p = new Project(slnTask, tfc, outputDir); 
 p.Load(sln, path); _cachedProjects[projectFileName] = p; 
} 
else if (projectExt == ".vcproj") 
{
 VcProject p = new VcProject(slnTask, tfc, outputDir);
 p.Load(sln, path);
 _cachedProjects[projectFileName] = p;
} 
else 
{
  throw new BuildException(string.Format(CultureInfo.InvariantCulture,
  "Unknown project file extension {0}.", projectExt),
 Location.UnknownLocation); 
}

• How does the build and deploy cycle work with multiple developers?

This technique thrives in the multiple developer environment since it provides an isolated predictable place (your integration server) to do all builds, tests, etc.  This guarantees that the build is easily reproducible and independent of your development team.  Your build should come directly from the source repository which then is the interface for concurrency issues on your team.  Certain protocols are still necessary such as don't check in code that doesn't compile or doesn't pass tests.

While the technique works well for teams, a single developer can still take advantage of a build and deploy technique.  The developer will gain many of the same advantages by always putting the build together in a predictable reproducible manner (even if he doesn't have a dedicated integration server).  It also allows new versions to be quickly deployed by automating the process.

• How do you manage versions and configuration across your QA environment (test, stage, prod)?

Configuration can be managed by either using the <include> task or subnanting.  Configuration within the application can be handled in a number of ways (file driven, database driven, etc) with NAnt copying over configuration files however necessary.

Versions should be moved across your QA environment using the idea of a "lastknowngood" build.  This "lastknowngood" version would be a successful build that has passed all tests.  It would be deployed to test then tested by the QA team then onto stage (then tested) and then production and so on ...  The idea is to move your build through each stage ensuring quality at each step.

Please note these ideas are just one way to do it.  NAnt provides a wealth of options and you can always choose the best set that meets your needs, environment and customer.