Scripting Deployit

All I wanted to do was create a number of plugins and examples for Deployit using the different techniques available. While working on examples I was frustrated by having to clean up remainders of previous attempts, so following in the footsteps of greater men than my humble self (most notably professor Knuth who created TeX so he could finish writing a series of books on computer science) I first wrote a script to create junk in the Deployit repository and then get rid of it in one sweeping go.

I’ve placed my code on Github (git clone git://github.com/jvermeir/DeployitBlogs.git).
To try out the examples you’ll need Deployit 3.8.4 (the version I used, but I’m quite sure it’ll work fine with other versions as well). I’ve installed the server and cli in a directory referenced by an environment variable $DEPLOYIT_HOME. I’m using *nix style variable and scripts in my examples. If you insist on using Microsoft you can always download Cygwin or change the examples yourself. After checking out the sources and installing Deployit, $DEPLOYIT_HOME should contain the following folders:
deployit-3.8.4-server
deployit-3.8.4-cli
DeployitBlogs

DeployitBlogs contains a directory named tools that for now holds no more than a couple of scripts, most notably three scripts named utils.py, cleanup.cli and deploy.cli. In src/test you’ll find a dar file I’m using to try out my scripts and plugins (deps.dar was build from another example I hope to explain later, for now it’s not important; all it does is copy some files and print a message to the console).
Utils.py isn’t really a script but a plugin. It is supposed to be placed in $DEPLOYIT_HOME/cli/ext, but that can become rather tedious very quickly if you’re going through lots of versions, so I left the script in the tools directory and created a symbolic link to it so the cli will pick up new versions when it is restarted. Create a link in $DEPLOYIT_HOME/cli/ext:
cd $DEPLOYIT_HOME/deployit-3.8.4-cli/ext
ln -s $DEPLOYIT_HOME/DeployitBlogs/tools/utils.py utils.py

One more piece of setup is necessary: create two test environments that are required by the scripts in examples I hope to discuss later. Open the Deployit client interface and create two environments named ‘localenv’ and ‘AnotherLocalEnv’. They should contain a overthere.SshHost named ‘local’ and ‘AnotherLocalHost’ respectively. I defined both hosts with default settings and a username of ‘deployit’, but the username doesn’t (yet) matter for the examples. It should exist though, so in my case Deployit just connects to localhost as user ‘deployit’ to run the scripts.
The scripts in cleanup.cli and deploy.cli are no more than convenience wrappers that make it easier to test new versions of the plugin. After some command line input checking all they do is call one of the functions defined in utils.py.
cleanup.cli is used as follows:
$DEPLOYIT_HOME/deployit-3.8.4-cli/bin/cli.sh -username admin -password admin -f $DEPLOYIT_HOME/DeployitBlogs/tools/deploy.cli -- $DEPLOYIT_HOME/DeployitBlogs/tools/src/test/deps.dar localenv

The command above starts the cli, connects using default credentials, starts the script named in the -f parameter and passes the two parameters following the double dash to the script.
To avoid even more typing I created a shell script d.sh that does no more than run the command line above. It takes the environment name as a parameter like this:
d.sh localenv

To call the cleanup script use:
c.sh deps

With all these details out of the way we can discuss the utils.py script.
utils.py is read by the cli when it is started. Each method in the script is available from the cli command line, but there are two main entry points:
def deployApp(fileName, environmentName):
def deleteApp(appName):

These are the methods that are called from deploy.cli and cleanup.cli respectively.
deployApp is nothing more than a straightforward deployment of an application from a dar file, like explained in the cli guide (climanual.html) you can find in the server/doc/html directory (open the file and search for ‘Performing deployments’).
Before it deploys an app from a DAR archive, deployApp calls deleteApp to erase all traces of previously imported or installed versions from each environment.
DeleteApp calls undeployApps (see picture below) to find all versions of the app and undeploys them so they can be subsequently deleted by the call to deleteVersions.
deleteVersions works like undeployApps: get a list of stuff to delete, loop and delete each version using repository.delete().

If you’re interested in the details you can clone the repo at
git clone git://github.com/jvermeir/DeployitBlogs.git
cd DeployitBlogs/
git checkout 94ff4af

The code for this blog is located in the ‘tools’ directory.