Closing in on a deadline at work, the developer teams were facing the truth, that their software had to leave their cozy development environment. In our case, we had a couple of Flash applications developed by loosely connected developer teams. We ran into a couple of problems when we tried to coordinate a proper deployment process. It was a good example of the part of software development that is rarely dealt with in books or at university courses, so I thought I’d list the problems here and mention the tools we used for deployment.

Problem: “But it ran fine on my machine.”

On software developer machines the operating system, installed libraries and development tools are tailored to get your software running. You need a library? You install it. You need a certain environment variable? You set it. Over time, that machine is going to be loaded with lots and lots of additional software and modifications. But of course, this is not guaranteed to be the case for the machine that will ultimately run the software.

A real life example are debug builds of software. Visual C++ software that is compiled and linked with debug settings rely on system libraries that have debug symbols as well. Such libraries are usually installed along with Visual Studio. But if you deploy a debug build to a non-development machine, the software will complain that the wrong versions of required libraries are installed.

Solution: Set up a reference deployment system.

Virtual Machines are a great way of providing a reference deployment system. The basic idea behind this, is to install a system with nothing but the bare necessities inside a Virtual Machine. Nothing but the absolute minimum requirements of libraries and software should be included. Take care that it only contains “release” grade version of software. Avoid custom compiled third party software or debug libraries as much as possible. Your user will most likely not have those.

Once you have set up the reference system and before you deploy you software to it, create a snapshot of your VM. This can be either done by duplicating the machines disk image or by the Virtual Machines own ’snapshot’ feature. The important point, is that you can revert the VM to its original pre-deployment state easily. Uninstalling the deployed software is not an equivalent option if it installs any libraries or changes system settings.

Problem: Manual deployment steps are prone to errors.

Software deployment consists of several steps. Building the binaries, gathering the additional files and packaging on the development system, unpacking and distributing the files to their places on the user system. The last two steps are usually done by software package management systems such as Installshield or RPM packages. However, providing these systems with the right collection of files and settings can be a very complex task, depending on your software. Copying them from your development system, updating setting templates, retrieving the latest documentation files from the version control system.. Every step of those can either be forgotten or handled improperly. The result is an faulty deployment package. Deploying an outdated documentation would be one of the lesser problems you can face.

Solution: Use a deployment script.

Something you learn quite early when starting with software development, is that you should use subroutines, methods or macros when code is used more than a few times throughout the program.

The same is true when performing the steps of assembling the files for a deployment package. Very quickly a file is missed when copying them to the deployment folder. Or the debug build was copied instead of the release build.

Sure, writing the script is a source for bugs and errors itself, but the time you spend on making a proper deployment script will pay off later, especially if you deploy testing packages in short intervalls.

The deployment script can do much more than just collecting the required files. It can also:

• Build the binaries. If possible, let the script not only copy the binary files of your software but also trigger the build process. The advantage is, that you can be sure that the binaries are created from the latest sources and that there will be only a binary deployed if the building process was successful.

• Update revision files. The revision or build number of a software is often stored somewhere in the deployment packages. A deployment script can automatically update those numbers, so you won’t forget it.

• Perform tests. The deployment script can perform sets of predefined tests on your software, checking if it behaves as expected.

• Archive the source. The script can archive the source and resource files that were used for the deployment, so that later on the exact status of the project can be reconstructed if an error occurs in a deployed package, but development has changed the source codes in the meanwhile.

A good example for such a deployment tool is “Apache Ant”, a scripting environment for software building, management and deployment.

In our case, an Ant script performs the SVN checkout, in some cases the build process, the file packaging and the deployment to the server. All of that takes nothing more than a double click on the developer’s machine.

Another big problem was the missing communication between the development teams. What problems that caused will be the topic of a different post.