Your organization invests a lot -- maybe your time for a week or fifteen months of engineering time or $385,000 of license fees -- in a piece of software. It works great on the demonstration host you've set up for it. When end-users try to benefit, though, there's just frustration: annoying misinstallations, configuration mysteries, irreproducible drop-outs, or programs that simply do nothing.
Something is deeply wrong, and it's far too common. The label I put on this aspect of computing is "deployment." Deployment is everything that happens between the time your boss or client says, "I like it!" when it's on your screen, and the time end-users call or write in to say, "This is what we've been waiting for."
In principle, that's a short step. Deployment isn't a deep subject in the way algorithmic theory, network load analysis, or even requirement acquisition, are. As an industry, though, we've collectively neglected, mishandled, and underinvested in deployment. The consequence is predictable: Several of the worst wastes in software development have to do with deployment. This month's "Server clinic" explains how you can achieve better in your own work.
Let's first look at an example to establish a common "feel" for what deployment involves. Suppose you've cooperated with a colleague in chemistry to develop an interesting computer simulation of the curing of cement. The two of you are quite proud of the way it works from your development server -- it handles a large space of atmospheric regimes, ground conditions, and so on. Great!
But sharing the work with other engineers doesn't go as smoothly as you expect. Small variations in installed C and Qt runtime libraries lead to quirky results, and even process aborts. A couple of peers are running Linux-over-AXP rather than Linux-over-Intel. One researcher works in an organization where all installations must be rooted in /var, and nothing is allowed in /usr/local.
The good news is that everyone in the work group has Linux, and finishing installations doesn't require you to sit at keyboards in Sweden and South Africa. The bad news is that, even with remote logins, you're still averaging over half an hour per delivered program. Before long, you've accumulated more time installing the program than you invested in first implementing it.
What makes this truly awful is that it's typical. The culture of information technology (IT) has institutionalized acceptance of such disasters. We accept that installation is fragile and error prone.
You don't have to accept that, though. Here's how you can make a difference:
Don't start by buying an installation product. As valuable as several are, understanding is more crucial.
And the most important thing to understand is that good deployment, like most aspects of computing, starts with good analysis. To manage your success in the example above, discipline yourself to write explicit requirements, such as:
- The application should be transportable or installable as a single-file image.
- The application should work on any Intel Linux host endowed with glibc 2.2-2.2.5.
- The application should require no other libraries, such as Qt, be present.
- The application must have IP connectivity during initial registration.
- When the application detects that one of its requirements has not been met, it writes an explicit diagnostic to the console, and exits gracefully.
- And so on ...
To operationalize such written requirements, I like to maintain executable installation procedures from the first day. Think, for a moment, about the reputation Extreme Programmers (for story, see Resources) have for writing tests before they implement the application to be tested. In the same way, I write at least simple installations before those tests. By keeping installation in the regression suite, I'm assured at all times that I can reliably and inexpensively relocate any version of my development to a customer's machine.
I'm in the minority in this. Many organizations invest large amounts in front-end analysis, diagramming, training, and other elements of development, but then casually send programmers out at the end of the cycle to reconnoiter for compilers, cross-compilers, license managers, and other tools to help with deployment. To the best of my knowledge, there's no formal research on the merits of each approach. What this column can contribute, though, is clarity on the alternatives. My own work proves that it's possible to incorporate deployment planning from the beginning. My experience convinces me that's the better way to work. Let your choice be an explicit one, not just the result of inertia.
Along with general managerial principles -- plan, make things explicit, compare costs and benefits -- deployment involves several specific ideas that you'll want to learn:
No installation program solves all problems
Deployment might involve delivery of software to a half-dozen mobile technicians, or the eighteen hundred desktops located in one building, or three hundred end-users spread all over the world. It might be to a platoon of identical hardware, or every host might be different.
Don't expect any one deployment system to fit all these situations perfectly. Don't despair, either; even though the problem might be bigger than you first see, it's almost certainly solvable. The one hazard in this regard is that it's easy for organizations to try to settle such matters by mandating a simple answer, sometimes even before the question is known.
Sometimes enthusiasts conclude that use of Java, or a particular
dynamic-linking scheme, or software depots, or configuration
management products, or another technical trick,
solve deployment problems.
None of these are universal, though. They all have costs as well
as benefits. Think for a moment about shared-object libraries.
Suppose you have seventy-nine applications on one server that are
all defective in that they rely on a faulty system printf().
With dynamic linking, you can update just one C runtime library,
and correct the internationalization of all seventy-nine
applications. This scheme requires, though, that all the
applications use the same version of the library, or at least
that new procedures manage the library version. Worse,
your installation procedure for end-users has to manage
both the application executable as well as any shared-object
libraries on which it depends. This leads to exactly the
sort of combinatorial complexity Microsoft Windows administrators know
as "DLL hell."
When you're conscientiously committing your deployment requirements to writing, pay particular attention to updating issues. What should happen when you update a host that already has your software installed? What if the existing installation is from a different version? Can different users on a single host see different versions, or should there be a single one for the entire machine?
One productive way to think about deployment and installation issues is in terms of the three aspects:
- Program
- Data
- Configuration
Suppose you're responsible for a word processor application. To install it satisfactorily, you need to
- Have the program proper in place
- Preserve any documents users have already composed
- Recognize the environment preferences, fonts, macros, display colors, and other cross-document conveniences users create
One of the reasons installation products can so rarely be used "out of the box" is that each of these three aspects is likely to require a different life-cycle through updates.
However demanding that sounds, keep in mind that you're far better off to capture such requirements early in development.
In the face of all these difficulties, how can you achieve successful results? First, keep things simple. For most development, I've abandoned sophistication about group IDs, signal-handling, and other secondary matters; many sites don't administer these rationally, and you only heighten your customers' frustration, along with yours, to try to "correct" their patterns.
The one model that is most pertinent to deployment is that of the file system. Exploit this. As flawed as it is, the user interface to the file system is at least familiar to most end-users. This is why I'm such a strong advocate of installing single-file executables (no accessory dynamic libraries, and so on), or images that unpack themselves into a single directory. These simple schemes give users a chance to understand whether a product is installed or not, how to uninstall it, and how to back it up.
That preference for simple file system-oriented installations inspires a corresponding affection for my favorite deployment technologies: commercial installers, self-unpacking binary bundles, "scripted documents," and "virtual file systems" (VFS). Scripted documents and VFS are large topics that deserve column installments of their own. For now, I'll supply brief definitions, point to online references where you can read more, and welcome you back to future "Server clinic" columns that will give more detail on these subjects.
"Scripted document" is the label independent consultant Jean-Claude Wippler uses for a file format of his invention. He supplies applications in two parts: an application-independent, platform-specific executable, and a platform-independent, application-specific "scripted document," which bundles executable code, user data, and persistence methods. These scripted documents are handy, at least for many of the deployment situations I encounter. They can be copied -- even to operating systems other than Linux! -- renamed, deleted, backed up, and so on, just like normal files in the file system. At the same time, they encapsulate all the information more conventional applications spread over several installed files or directories.
Until "Server clinic" returns to the topic, you can read a few of my notes on scripted documents in Resources, below. In the meantime, remember that deployment is a serious enough subject to do right, and that the first step to doing it right is to document your requirements.
What specific deployment challenges do you face? Join me in the discussion area nearby, and perhaps other readers and I can help.
- Participate in the discussion forum.
- Check out the other installments of Server clinic.
- Distressingly little has been written about deployment. Several
books are in print on deployment issues for specific flavors of
the Windows operating system, but a good
reference text on the general subject does not yet exist. Along
with the suggestions here, it's wisest to read
introductions to the topics of configuration management,
requirements analysis, test, system administration, and user
interfaces. For example, The Practice of System and Network
Administration, highlighted in last month's "Server clinic"
has a useful chapter on "Software Depot Service," along with a dozen
more diffuse items that bear on deployment more subtly.
- "The
Jericho Itch"
is Jean-Claude Wippler's jeremiad on the misery of present-day
installation practices.
- For more on producing high quality software, read the article on Extreme programming (developerWorks, April 2001).
- Find more Linux articles in the developerWorks Linux zone.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
