The deployment role is often overlooked--much to the pain of the users. The actions of this role are the final step before being able to hand over the code to the users for their first real road test of the solution. It is the deployment person who can have the largest impact on the initial perception of the software for the people who are first trying it out. (If you've not been following the series, you should read Cracking the Code: Breaking Down the Software Development Roles.)
Success here can hide quirks in the solution, but failures here can give the wrong impression about the software.
What's the deployment role?
A software solution of any complexity will have dependencies that must be present before the solution can be used. Many of these dependencies go unstated. For instance, a Java program needs a certain level of the Java runtime environment installed to be able to run. .NET based applications require a specific version of the .NET framework and common language runtime to run. In the case of database applications specific versions of the software drivers to connect to the software to the database are required. The chart below shows how the Deployment role fits within the full organizational chart.
In addition to these software dependencies, there may also be hardware dependencies. This could include a minimum amount of member, a required amount of hard disk space, access to multiple machines (such as a database server versus an application server), access to the Internet, and more.
The more complex the solution, the more prolific the requirements are. Solving that problem is the role of the deployment professional. It is the focus of the deployment role to create a program that constructs the operating environment that the solution needs. This includes installing prerequisites, making necessary configuration changes, identifying conflicting software, and manipulating any other components of the environment that the solution may need.
The first step in the deployment role is to identify and test by hand all of the steps necessary to make the software work in an environment. These instructions are often written as complete documentation so that even without the installation program they can install the software. These installation instructions sometimes serve as the early procedure for installing the software through alpha pre-release program and even throughout the life of the software if it is installed to a small enough group of clients.
From the installation instructions, an installation program is constructed to automate the steps identified during the creation of the installation instructions. The program must do more than just install the system, it must also, in today's world, be able to uninstall the software once it has been installed. This must also be done in a way that is respectful of the other software that is already installed in the customer's environment. Figuring out how to be a good software citizen with an installer is one of the most challenging things that any software development team can do.
It is challenging for a variety of reasons but none more important than the need to understand both the software development process as well as an understanding of the operating system and the network infrastructure that may be used to deploy the software. The requirement for understanding the software development process may seem obvious. They're a part of the process so they should understand it; however, the required understanding goes deeper than this. They must also be able to identify inherent dependencies created by the development process that may not readily be obvious.
A command of the operating system (or systems if the software is to be used on multiple platforms) is also necessary since it will be the deployment professional role to manipulate the operating system from their installation program. The subtleties of whether to register a .NET assembly in the global application cache or not is an important thing for a deployment specialist to know. Considering all of the code access permissions and learning how to setup those permissions so that the user will be able to run the application is also important.
The final component that the deployment professional must understand is how automated deployment tools, such as Group Policies in Active Directory and products like Microsoft's Systems Management Server, deliver software to the clients and how the installations must be constructed when being deployed via these mechanisms. This is a critical consideration when the software will be deployed across the enterprise since it's not feasible to go install the software manually on each machine.
The final consideration for what the deployment professional will do is creating patches. Software teams necessarily create updates to their solutions. These updates need to be deployed to systems just as the original program was. Most consumers expect that the patches that they receive today will integrate into the existing installation rather than being another program that must be added or removed. Deployment professionals are entrusted with developing strategies that deliver patches efficiently.
Getting started as a software deployment professional
With the broad range of skills and the extensive experience requirements you might think that getting started as a software deployment professional might be hard to do. In truth there are two paths that can be used reach the software deployment professional role.
The first way to start is to work on the help desk, servers, and networking side of an IT department. In this role dealing with installation problems, trying to find workarounds for issues, the intimacies of the operating system and the network are revealed. From there it's simply a matter of volunteering to work with the software development team to help software get installed in the environment as well as possible. Since many software development teams, particularly those inside of an organization, don't have a dedicated person filling this role they often welcome the help.
The second path to becoming a software deployment professional is to work as a developer and focus on identifying issues that may become challenging during deployment. That means paying attention to the steps to setup a developer box and documenting them. It means looking for things in the code that may create deployment issues. From here it's natural to get involved in troubleshooting issues when deployments are done. Once you're troubleshooting the problems of deployments the role of the software deployment professional is in easy reach.
The deployment professional role is often combined with one (or more) other roles. Because deployment isn't always what is called for, deployment professionals may fill the quality assurance role, a developer role, or other roles along the way. The deployment role may be one that you'll find yourself volunteering for from your primary role .
What's in their toolbox?
The toolbox of the software deployment professional is a grab bag of small tools that can help work around limitations and quirks with deployments and a few larger tools designed to construct the installation programs themselves. Following are a few of the tools useful to the software deployment professional.
- Batch files -- Batch files, which are the legacy inherited from DOS, is the most basic way to string together a set of commands. Batch files are showing their age with minimal error handling, messaging, and branching capabilities. However, they work on nearly every system so they are often a quick way to work through problems and are a quick way to glue together different operations.
- Scripting Languages - The inclusion of WSCRIPT and CSCRIPT utilities in the operating system have made it possible to use VBScript as a way to create more robust strings of commands with better error handling and a better ability to message. Many other, proprietary scripting languages exist as well. These languages typically require the installation of a tool on the workstations to be able to run the script. Scripts are used because they are able to do things that are not possible from batch files and are still easy enough to put together that they can be used quickly.
- Packaging Tools - The core tool for the software deployment professional is a packaging tool. In Windows these tools create a Microsoft Installation (MSI) files and can create patch files (MSP). These tools create a specifically formatted database that the installer service in Windows can read and perform actions. Extensions in the installer format allows for user provided code to be run. Wise and InstallShield have been the historical leaders in this market. Microsoft has recently released a Windows Installer Xml (WIX) project to open source that is very promising.
- Package Management Tools - Occasionally it's necessary to snoop on the package that was created. It may need to be taken apart, monitored while running, or unwound into a set of related files. In the MS Platform SDK you'll find a set of tools for opening, reviewing, and manipulating MSI files. These tools are invaluable for troubleshooting problems with MSI files.
- Virtualization software - With software such as VMWare and Microsoft's Virtual PC, the deployment role has gotten easier. Rather than having to have numerous machines with different configurations to leverage as a test, the deployment engineer can have several virtual environments. This saves time because they can simply fire up the virtual machine and go. It's even more useful in keeping the amount of space required for the deployment engineer down since they won't have to have a dozen or more computers that are used infrequently for testing.
- Disk Image Software - Virtualization software have features that allow users to undo changes that can be very useful for testing. It allows you to try different variations without having to reinstall between attempts. If it is necessary to work on physical hardware instead of virtualized hardware then a software which copies the drive image into a file which can be restored to the machine after a test, such as Symantec Ghost, is a must. It substantially cuts down on the time spent rebuilding test systems.