Scripted Deployment

The commands to deploy an application are written in a scripting language. The script is executed, and the commands are executed in sequence. The scripting language may be a shell script or batch file, or it may be a higher level language -Perl, Python, Ruby, or a build-tool language such as Make or Ant.

Features

• The sequence of commands to deploy an application are listed in a scripting language
• The runtime interprets the scripts and executes the command
• The scripting language can contain control logic to order the deployment.

Advantages

• Shell histories can be used to build the commands for shell-scripts.
• Build-tool languages can integrate deployment with build process, and can order actions by declared dependencies.
• Offers the complete functionality of the language
• Developers may be familiar with the language
• Procedural programming is something that all developers are familiar with
• Scripts are easy to execute on the command line
• Big deployments can be built by aggregrating smaller sequences.
• Variables can be used to share configuration options and results between stages of the deployment.
• Return values and the output of programs can be fed into the shell's decision making process.

Disadvantages

• Requires a good language. Windows batch files have historically been very weak here.
• Requires applications that can be configured from the command line. Again, windows has been very weak here. Unix has been much stronger.
• Does not scale to a single deployment choreographed across multiple machines. You can run the same script on many machines, but trying to have a single script that starts the database in one machine, and the application server in two others is not easy.
• No way to rollback except through the authoring of separate scripts
• No automated liveness tests.
• No easy for programs to examine the scripts and determine what their side effects will be.

Declarative information is the key to making tools such as Alien work; this cross-distribution installer can read RPM metadata and install the described artifact on .deb systems...the declarative aspects of an RPM file can be translated into the .deb equivalent. Scripts cannot be translated, or understood on a machine except by executing them and observing what changes have taken place.

SmartFrog support

SmartFrog is clearly positioned as an alternative to scripting, because we believe that model-driven deployment is a better way to describe complex, distributed applications.

Even so, we know how popular scripts of some form or other, be they the scripts to start up databases or application servers, or existing Ant build files. The runshell component (/org/smartfrog/services/os/runshell/components.sf can execute a shell script on startup; parameters to the script can be used as part of the model. The ShellScript components /org/smartfrog/services/shellscript/components.sf are more powerful, as they start a shell script to which commands can be issued by remote callers. This can be used to connect together the inputs and outputs of processes running on different machines. Script failure can be detected and reported. What SmartFrog cannot do is automatically roll back the changes made by the script during undeployment.

For Ant integration, the sf-ant components offers complete access to Ant's own tasks as SmartFrog components, and the ability to execute Ant build files within SmartFrog's own process. What SmartFrog cannot do is automatically roll back the changes made by the build file during undeployment.