Sunday, September 2, 2007

Automated Builds - Test Driven Development

Your development process can be improved if you automate your build process and implement some form of test driven development. All of us have been on projects where the integration phase takes a long time, often longer that the development time itself.
By taking steps toward automated builds and test driven development over time, you will make the integration process a non event. The mantra is “Find as many issues as possible, as early as possible”.
The first step toward automated builds is to develop a script that extracts everything from version control and builds your system using one command. The goal is to be able to visit an empty machine and build your app with this single command.
This means that everything you need for you application should reside in version control. This includes database schemas, stored procedures, views, seed data, source code and ideally, unit tests.
If the build succeeds, an installation package is created and success notification emails are sent to a distribution list. This installation package is stored in a drop folder and made available to anyone who needs it.
nAnt is a good open source tool that can perform these tasks.

Version Control
The heart of automated builds is Version Control. Everything necessary to build your application should reside here.
Your database schema represented in the form if a SQL script resides in Version Control. Ideally, this script should be created using a database modeling tool. The modeling tool creates the script and is stored in version control.
All of the scripts necessary to create your stored procs, views and other programmatic database objects reside in version control as well. A master script that executes these scripts in the proper is also required. It is not a good idea to develop database objects directly in the database. Always develop database objects via scripts.
The final database task you face is the scripting necessary to populate seed data. This could be lookup tables and other data necessary to operate your application.
Of course, all of the source code for you application must reside in version control. It is also suggested to include the source code for your unit tests. nUnit is a very good open source tool for unit testing.
When a build is successful, we will create an installation package. This could be as simple as a zip file with installation instructions or an MSI file to automate the install. Anything necessary to facilitate the install should be in version control as well.

The Build
A single command should perform the build. nAnt is an excellent scripting based on the popular Ant setoff tools in the J2EE world. nAnt should perform the following general steps:

  • Cleanup – Perform any cleanup from a previous build. Delete any executables, config file or other objects.
  • Drop Database – Drop the database that was created from previous builds.
  • Extract From Version Control – Extract the files from version control.
  • Build the Database – Create a new empty database. Execute the schema script, Script for Procs and views and seed data script.
  • Compile the application – Perform a compile of the application and unit tests.
  • Execute the Unit tests – Use the batch option to execute all of the unit tests for the application.
  • Failure action – If any of the above steps fail, send a failure notice and log to failure distribution list.
  • Success action – If the build succeeds, build an installation package and send an email to the success distribution list. The installation package is available to QA or anyone who need it.

In Closing
Even though it is a challenge to get an automated build setup the first time, it is worthwhile. If the build is run every night, problems are uncovered on a daily basis instead of being pushed to the end of the project.
The following links provide useful information on this topic:

1 comment:

Fragmentadora de Papel said...
This comment has been removed by a blog administrator.