Custom Deployment Scripts: Pluses and Minuses
If you
take a look at the survey on our home page, you'll see that a surprising number
of visitors use a custom script to handle their network software deployments.
Why is this? Many have tried one of the more well known products like SMS or
Tivoli, ran into problems and in the process of scripting solutions around the
problems, developed an entire scripted solution. Cost is another key reason for
going with a customized deployment, purchasing deployment software and client
licenses become an increasing issue as the size of the network to be managed
grows in size. Automation must exist, configuration management is impossible to
maintain without some level of centralized management. Increasing the cost of
many commercial off the shelf (COTS) products is the fact that so many include a
suite of applications or some framework, which by definition, is very complex
and even more often expensive. A final reason, not often considered, is that
until AppDeploySM there was nowhere to learn of the competition to the more
recognized products and their capabilities. Being that the market for
application deployment tools is still very immature, there has been little
information to assist administrators in making an educated choice which best
meets their needs.
However
there are also several reasons not to go with a customized solution. One large
one is support. A COTS product provides you with a help desk, regular updates,
documentation, and in some cases training and technical papers. The support that
comes with a customized deployment script is limited to what can be accomplished
by the individuals familiar with the script. This brings to light the largest
problem, normally there are only a small number of people intimately familiar
enough with the script to troubleshoot problems and implement enhancements. The
retention of these individuals cannot be guaranteed. For this reason, thorough documentation is essential. It is
very common that documentation for custom deployment scripts is poor or
non-existent. Optimally, documentation would pull apart and explain the script
to a level that anyone could understand. Finally, almost all scripted solutions
rely on the population and placement of text files that can be easy to confuse
as compared to the simplicity of a graphical user interface. Blinding the
operator of the script from seeing exactly what actions are taking place can
have potentially catastrophic effects for inexperienced operators.
Take some steps toward a making an educated
assessment of your situation. In the creation and use of custom deployment
scripts, sufficient experience should be on hand to develop a proper set of
requirements for a COTS replacement. A list of what you need in a replacement is
essential. There may be no product that meets your requirements; there may also
be some essential functionality you didn’t consider. This may be an exercise
fraught with resistance by those who generated and maintain the custom script.
However these are the people who know the requirements best, and are therefore
essential in the process of building and researching a COTS replacement.
If and when solutions are
uncovered, it may still not be the right time to make a switch. Financially
there may not be the money available for the product and there may be increased
deployment activity taking place that requires you to stay on track until a
later date. But don’t catch
yourself waiting for the time when no deployments of updates, fixes or new
software is taking place- that day may never come.
Bob Kelly
3/30/2000
Comments