Originally published on Developer.com, July 11, 2005.
The deployment role is a role that 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. Click here to see how the 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.
Where’s the position heading anyway?
More and more consumers are getting computers. The average level of knowledge on computers is decreasing while the total number of customers is still increasing. Because of this the demand for software deployment professionals is growing. Instead of software being installed with a batch file the program must today be installed through a large number of slightly changing steps. The larger number of installations requires more sophisticated handling. The lower tolerance for problems with software due to lower knowledge requires that installations be more bullet proof. The good news is that this means a greater need for software deployment professionals. It’s more important than ever to be able to deploy software quickly and easily.
The difficulty level is going down even as the complexity goes up. The installation tools, often the last thing thought of by the industry, have been making good progress to get better. The release of Microsoft’s Windows Installer XML (WiX) toolkit is encouraging since it is making it easier, and less expensive, to develop installation files that the Windows Installer service can install.
The Good, the Bad, and the Ugly
The deployment professional can often times experience the good, the bad, and the ugly of their role all in one day. They can see the software get deployed across the organization – only to find out that here was one application it wasn’t tested with, and that one application is one of the mission critical applications for the organization – which the installation just broke. Here are just a few of the good, bad, and ugly things about the deployment role:
- Good: High Impact – The role is one of high visibility and high impact to the user community. When done right it’s easy to save hundreds of hours time for the users.
- Good: Often get to use a number of different systems with a number of different configurations. This can be fun!
- Bad: Never Enough time – Being near the tail end of the process the installation often gets rushed. The testing time to ensure that the installation doesn’t break other applications is often hard to come by.
- Ugly: Difficult to get right – Building good installations is still very technically challenging today. Over time good deployment processionals learn how to avoid big mistakes, however, even veterans are known to make mistakes that has huge impact.
- Ugly: No matter how many systems you test your installation against, it always seems that a user will have a system that is slightly different. When something goes wrong with the installation, this person gets blamed.
Conclusion
The deployment role is one that is critically important to the initial impression of the software being delivered. A bad installation experience can sour just about anyone’s taste. Because of this the role of the deployment professional is increasing. Although professionals are still often shared with other roles the deployment role is one which continues to grow.