Deployment scripts should always be refreshed from VCS prior execution

After few months of continuous deployment scripts writing for a pretty complex architecture (two JBoss instances, a mule ESB instance, one database to reset, a BPM server, each being restarted in the right order and running from different servers), I figured out a good practice in this field : scripts have to be auto-updated.

When dealing with highly distributed architectures, you need to install this kind of deployment script (mostly Bash) on every involved node and it becomes soon very cumbersome and error prone to maintain them on every server.

We now commit them into a VCS (Subversion in our case), it is the master location of the scripts. Then, we try :

1. To checkout them before running when possible. For instance, we used a Jenkins job to launch our deployment process (written as a bash script). The job is parametrized to checkout the SVN repository for the script before running it from the Jenkins workspace. This is very convenient.
2. When this is not possible (for instance when the script should be executed on another server than the CI server), we checkout the script from the Jenkins server and push them (using scp for instance) to targeted server before executing it (using ssh).
3. Sometimes, when the call must be asynchronous on another server, we simply trigger a script by creating remotely an empty file. A very simple croned bootstrap script (not refreshed itself) detect the file change, update the script (svn co) and run it.