Home > Articles > Custom Deployment Scripts: Pluses and Minuses

 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