This primer is broken up into major sections below.

Moving Files

If you are like me your web server isn’t the same machine as your development PC at least I hope not! You will need a way to get files to your web servers.

Push: Push deployments are when files are transferred from the client to the server. An example of this would FTP, or many other file transfer protocol. This involves opening up a client, and manually or automatically transferring the files from your PC to another computer. This could also involve transferring them using a network file system. FTP clients are included with most major operating systems.

Pull: Triggering the server to download files from another location. An example of this would be using a third party program to download the files from web or ftp directory. WGet, SVN, or another similar program could be used.

WGet: Gnu WGet is free software for retrieving files over HTTP

FileZilla: Open source FTP client and server.

Source (Revision) Control

Source control is critical for being able to control releases, and code. Source control allows you to version your applications, and download a particular version from your source control repository. There are many flavors of source control. Personally I prefer Subversion (SVN). For information on source control.

SVN: Open source, source control client and server.

CVS: Open Source, been around since the 80’s, Concurrent Versioning System

Mercurial: Open Source, Distributed Version Control in Python.

GIT: Open Source, Distributed Version Control

Bazaar: Open Source, Distributed Version Control

Visual Source Safe: Microsoft’s Legacy Version Control

Team Foundation Server: Microsoft’s Prefered Version Control, as well as project tracking

Automation

When I first started building websites. All my deployments were done manually over FTP, and it sucked! Then I started using a better FTP client, and guess what it still sucked! I dreaded deploying, it was error prone, and I looked like an idiot because I forgot a file here or there. It all changed when I started automating my deployments, and I haven’t looked back since.

Depending on what language, or platform you are developing on or for. It is very likely there is an automation application for you system. There is a large class of open source build automation applications based in some way off ANT for Java, which is java version of MAKE.

ANT and it’s derivatives are build scripts which are programmed using XML. Using the ANT XML files you can control file copying, running builds, unit tests, and a number of other deployment and build related tasks. Most of these applications support building custom tasks in their native language, so if it doesn’t support what you need it is very easy to build on top of these platforms.

Make: GNU Build Tool, best suited for compiling applications, custom file configuration.

Ant: Java Build Tool, best suited for building and deploying Java applications.

NAnt: .NET port of Ant, best suited for building and deploying .NET applications.

Phing: PHing Is Not GNU make, best suited for deploying PHP applications.

Maven: Similar to Ant, but different application, it is network ready, and uses a system know as the Project Object Model.

Rake: Similar to Make for Ruby, and the config files use a Ruby syntax.

Other Techniques and Tools

Divide and Conqueror

Divide applications deployments up into different sections, so it is very easy to pin point major errors. One example of this is dividing a compiled web applications into binary, and non binary changes, and then deploy one after the other.

Differential

Create a deployment of only the files that have changed since the last release. An example would be using source control to download files that have changed, and only deploying those. The advantages are it will reduce time during deployment. It may also have the issue of missing files, or other items.

Putting it all together

These are just some of the building blocks for deployment strategies. Building a consistent deployment structure will depend on the number of production, and QA environments that host an application. Sometimes you may not even have access to the production servers. These techniques, and tools are very flexible to support even the most rigorous of deployment structures.

The deployment process should never be a source of stress, and deployment processes should never be the source of errors. Using a consistent, and stable deployment process will reduce both stress and errors.

Bookmark It

I have provided the entire text file listed below, and also a zip file with the template in a NAnt .build file for download.

Download
Template

Template code:<project name="Killer.NAnt.Template" default="Deploy.Target" basedir="." ><!-- Ian Lintner --><!-- www.dotcodedump.com -->

  <!-- GLOBALS SECTION -->  <property name="Global.Debug" value="false" />    <property name="Global.Project" value="[Project Name]" />  <property name="Global.Email.From" value="[Email Address]" />  <property name="Global.Email.To" value="[Email Address]" />  <property name="Global.Email.Server" value="[Email Server]" />

  <!-- DEPLOYMENT SECTION -->

  <target name="Deploy.Target" description="A generic deployment target" >      <echo message="**************************************************************" />      <echo message="* === Begin Deploy Target 1 ===" />      <echo message="**************************************************************" />      <echo message="* Time: ${datetime::now()}" />      <echo message="**************************************************************" />

      <!--Put Deploy Specific Varaibles Here-->

      <!-- Put Jobs Here -->      <call target="Job.One" />

      <echo message=""/>      <echo message=""/>      <echo message="**************************************************************" />      <echo message="* === End Deploy Target 1 ===" />      <echo message="**************************************************************" />      <echo message="* Time: ${datetime::now()}" />      <echo message="**************************************************************" />  </target>

  <!-- JOB SECTION -->

  <target name="Job.One" >      <echo message="**************************************************************" />      <echo message="* -== Begin Task One==-" />      <echo message="* Time: ${datetime::now()}" />      <echo message="**************************************************************" />

      <!--Put Job Specific Variables Here-->

      <!-- Put Actions Here -->      <call target="Action.One" />      <call target="Action.Two" />

      <echo message=""/>      <echo message=""/>      <echo message="**************************************************************" />      <echo message="* -== End Task One==- " />      <echo message="* Time: ${datetime::now()}" />      <echo message="**************************************************************" />  </target>

  <!-- ACTION SECTION -->

  <target name="Action.One" >      <echo message="**************************************************************" />      <echo message="* Begin Action One: ${datetime::now()}" />      <echo message="**************************************************************" />

      <!-- put tasks here -->      <echo message="   *** Task One ***"/>

      <echo message="**************************************************************" />      <echo message="* End Action One: ${datetime::now()}" />      <echo message="**************************************************************" />

  </target>

  <target name="Action.Two" >      <echo message="**************************************************************" />      <echo message="* Begin Action Two: ${datetime::now()}" />      <echo message="**************************************************************" />

      <!-- put tasks here -->      <echo message="   *** Task Two ***"/>

      <echo message="**************************************************************" />      <echo message="* End Action Two: ${datetime::now()}" />      <echo message="**************************************************************" />  </target>

</project>

View All of the Killer Nant Scripting Articles

Bookmark It

An example of this would be, I have to copy files, but I can’t until I backup my files. You could put the back up call in depends. If you use depends, you lose the ability to call variables in the current task.

How to use <call>:

<!-- Using Depends -->

<target name="task.build" depends="action.build.project, action.copy.to.beta" >

</target>

<!-- Using Call -->

<target name="task.build">   <property name="action.source.dir" value="\\path\to\folder" />     <property name="action.output.dir" value="\\path\to\folder" />     <call target="action.build.project" />     <call target="action.copy.to.beta /></target>

When we use depends, it has to happen before our script runs. Call is more flexible, because you can then scope variables to use with the tasks you are calling, and it does not control the structure of your scripting.

View All of the Killer Nant Scripting Articles

Bookmark It

Extending NAnt one step further you can even create your own custom NAnt assemblies (.dll), for truly flexible tasks. We will focus on doing it in the script, becuase the name of the game is getting it done quickly, without alot of overhead, it’s scripting damnit. If we wanted something else we would just fire up Visual Studio and create a application to do it for us. If you find your self doing extensive amount of programming in NAnt you may want to reconsider NAnt for the task at hand.

<script language="C#" prefix="demo" ><code><![CDATA[ [Function("generateguid")]public static string getguid(  ) {

   return Guid.NewGuid().ToString; }]]></code></script>

<target name="Action.Print.Demo"><echo message="*** My Guid is: ${demo::generateguid()} ***" /></target>

Bookmark It

Logging is logical extension of creating usable output from any type of computer program, be it a windows GUI, a web application, or even a script. Logging allows us to get into the nitty gritty about important steps our programs are executing. This goes one step further into creating really polished, functional scripts. Once we can track what is going on we remove some of the mystery of what is going on.

There are two ways to log, one is through the command line, and the other is the task made available through the NAnt contrib library. The task allows us to save portions of our scripts to files.

To call the record task, we pass it the path of the log file, which we specified with a global variable for the directory, and local action variable and the parameter action=”start” to start the recording task, and then we call it again after the actions we wish to log, and but with the action=”Close” property.

Record Task Example:<!-- Start Logging --><record name="${global.log.dir}\${action.log.file}" level="Info" action="Start"/>

<someaction .../>

<!-- End Logging --><record name="${global.log.dir}\${action.log.file}" action="Close"/>

If you wish to log without using the NAnt contrib library, you can use a simple solution, at the command line redirect the output using ‘>’ . We can redirect the output to a file and save it.

Run our script from the command line normally, but then append > “mylog.txt” to log the output.

Use -e (emacs ouput) to remove some of the excessive NAnt output artifacts.

C:\> nant /f:buildscript.build -e /v:+ all > "mylog.txt"

This will redirect the output of the build script to mylog.txt.

View All of the Killer Nant Scripting Articles

Bookmark It

If you are going to be writing one off scripts, this could be considered a “optional” addition to Nant scripting.

Displaying information well is one the most difficult tasks we as developers face, and with scripting it is very easy to ignore this section. Nant scripts with out well formatted output can be black boxes, that just do a task, and it’s magic. Formatted output and display allows the person using the script to view what is going on, and say “oh it got stuck when copying this file”, “This step was missed”.

Time to get to the scripting.

The output command in Nant is echo:

<echo message="*** I am a formatted Message ***" />

Using echo we can create nice output structures. Here is an example of output to use at the start of an action, and display an important variable called source:

<echo message="**************************************************************" /><echo message="* Task: ${task.name} " /><echo message="*" /><echo message="* Starting Action: ${action.name}: ${datetime::now()}" /><echo message="* Source: ${action.source}" /><echo message="*" /><echo message="**************************************************************" />

We can display information while scripting, that is more useful to the person who needs to run the script. I mostly use these for status updates, and displaying important variables in my scripts, so I can locate exactly what happened, and what is wrong. Good output is rarely appreciated till there is a problem with the script, and exactly what went wrong has to be figured out.

View All of the Killer Nant Scripting Articles

Bookmark It