Build Automation

Build Automation and Release Management Best Practices

I’m going to bundle all the scripts and docs here into a project called “BuildQuick.NET” on CodePlex.

Build tools and options

1. NAnt ( core framework for automating builds )
2. Maven ( high-level build tool (and more) that simplifies making builds )

The scripts and documents shown here represent some POSSIBLE approaches to build automation.
I’ve provided a level of organization, conventions and patterns to build automation but definitely not as robust and scalable as Maven.

Build Automation Steps:

Clean Delete existing source code and any other files part of the build, so that all the source can be obtained again with a fresh update test
Get Sources
Get the latest code from source control
Versioning Update the version numbers in your AssemblyVersion.cs file ( the file is autogenerated ) and contains the attributes declaring the version info of the project.
Compile Compile all the source code.
Unit test Run the NUnit / MBUnit tests
Fx Cop Run Fx-Cop analysis on the projects / dll’s
Code Coverage This steps involves performing code-coverage analysis on your code to determine how much code is covered by unit-tests. This can also include source code metrics.
Tag sources Create a label or tag source code in the source control repository so each build can be identified and obtained for the future.
Configure This step involves configuring the build so that it runs against the appropriate environment( DEV, QA , PRODUCTION ).
Deploy Deploy the build to for users to test. At this point, it’s it fully configured to run.
Backup Make a backup of the source code for this build

NAnt Build scripts:

I typically set up the nant scripts in the following way:

  • Have an NAnt script for each build action ( see table above and below )
  • Have a simple batch file bq ( BuildQuick ) that invokes any build script
    The batch file bq requires a parameter which is the name of the build script to run
    Example:
    bq Compile
    Contents of bq.bat

    nant.exe -buildfile:%1.xml
  • Have most ( not all ) of the build scripts re-used in CruiseControl.NET
  • Have a global settings containing variables for all the scripts
    ( see section below )
Action NAnt Script Batch file command
Clean Clean.xml bq Clean
Get Sources GetSources.xml bq GetSources
Versioning Version.xml bq Version
Compile Compile.xml bq Compile
Unit Test UnitTest.xml bq UnitTest
Fx Cop FxCop.xml bq FxCop
Code Coverage Coverage.xml bq Coverage
Tag Tag.xml bq Tag
Configure ConfigEnv.xml bq ConfigEnv
Deploy Deploy.xml bq Deploy
Backup Backup.xml bq Backup

Reasons for running NAnt Build scripts

I typically have the need to run my scripts from my machine for some reasons outlined below:

  • Automate build if you do NOT already use CruiseControl.NET.
  • Leverage same build script code locally and from CruiseControl
  • Providing a custom build from my machine to demo new features to business users.
    This is if I do not have my code checked into a separate branch, and do not have
    a project in CruiseControl.NET to build off the branch.
  • Testing related purposes ( Testing the build automation itself. )
  • Unavailability of cruise control ( Happens once in a while )

Global settings:

I keep a single settings file containing all my settings ( nant properties ) for all the build scripts above.
This gives a consolidated way to manage and modify them.
globalSettings.xml

 

<!– APPLICATION level –> <property name=“app.base.dir” value=“D:\Dev\Apps\StockOptionsApp1”/> <property name=“app.source.dir” value=“Src\Lib”/> <property name=“app.publish.dir” value=“D:\Dev\Apps\Builds\StockAppLatest”/> <property name=“app.test.dir” value=“Src\Tests”/> <property name=“app.name” value=StockOptionsApp1 /> <!– COMPILATION properties –> <property name=“compile.configuration” value=“Debug”/> <property name=“compile.target” value=“Rebuild”/> <property name=“compile.solutionOrProject” value=“${app.base.dir}\ide\${app.name}.WebSite.sln” /> <property name=“compile.workingDir” value=“${app.base.dir}” /> <!– UNIT TEST properties. –> <property name=“unittests.testrunner.path” value=“D:\DevTools\nunit-2.4\nunit-console.exe” /> <property name=“unittests.projectFile.dir” value=“${app.base.dir}\Build” /> <property name=“unittests.projectFile” value=“application.nunit” /> <property name=“unittests.config” value=“Debug” /> <property name=“unittests.xmlResultsFile” value=“${app.base.dir}\Build\Output\unittest.Results.xml” /> <property name=“unittests.workingDir” value=“${app.base.dir}\src\Apps\Web\${app.name}.WebSite\bin” /> <property name=“unittests.logfile” value=“unittestlogfile.txt” />

CruiseControl.NET and Integration with NAnt Scripts:

I typically have the following setup with cruise control projects:

  • Have CC Projects call almost all NAnt Scripts above ( to re-use build script code )
  • Have different CC projects for different types of builds
  • Allow CC to manage updating of sources
  • Allow CC to manage my version numbers for builds ( you can customize this )
    ( CC will call the versioning.xml build script passing in the version number)
  • The version numbers are stored in a “.state” file on the server.
  • I typically make it <major>.<minor>.<patch>.<build>

Type of projects / builds in CruiseControl.NET

StockOptionsApp_Latest This Continuous integration project builds the latest code on the head/main branch.Unit tests, Fx Cop, Code Coverage
StockOptionsApp_Latest_QA Similar to CI above, with following additions:1. Versions the build
2. Labels / tags the sources
3. Configures files to make it appropriate for a QA environment
4. Deploys the build to a network location for access

We run this every night, so our QA team ( and us ) always have access to latest code.

A QA team may only decide to test a specific build but it’s good practice to always provide access to a build with the latest code.

StockOptionsApp_Latest_PROD Similar to QA above with following changes:1. Configures files to make it appropriate for a PROD environment
StockOptionsApp_2.5.1_QA This represents an automated build off a branch 2.5.1 which as an example could be the production version.Assume 3.0 is the development version on the Head / Main branch.

This project automates a QA build of the 2.5.1 version.

(Fixes / patches to production build are done on this branch)

etc….

Cheers!

-Kishore Reddy

Responses

  1. […] This is summary check list of best-practices for build automation. For a more complete documentation on the subject, check out this post: Build Automation Best Practice Guide […]

  2. very informative


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: