From your question's wording I assume that you have a local machine and a remote machine where you update two files — a Python script and a Bash script. Both files are under SVN control, and both machines have access to the same SVN server.
I am sorry I do not have any advice specific to your grid system, but let me list some general points I have found important for any deployment.
Keep production changes limited to configuration changes. You write that you have to "use the datasets' path on the server"; this sounds to me like you have the paths hardcoded into your Python script. This is not a good idea, precisely because you will need to change those paths in every other machine where you move the script to. If you commit those changes back to SVN, then on your local machine you will have the remote paths, and on and on ... (What if there are not only paths, but also passwords? You should not have production passwords in an SVN server.)
So, keep paths and other setup informations in a .ini
file and use ConfigParser to read it, or use a .json
file and use the json module. Keep one copy of the file locally and one remotely, both under the same path, both without SVN control, and just keep the path to that configuration file in the Python script (or get it from the command line if you can't keep both configurations under the same path).
Keep configuration as small as possible. Any configuration is a "moving part" of your application, and any system is more robust the less it has moving parts. A good indicator of something that belongs into configuration is exactly that you have to edit it every time you move the code; things that have not needed editing can remain as constants in the code.
Automate your deployment. You can do it via a Bash script on your local machine; note that you can run any command on a remote machine through ssh
. For instance:
svn export yourprojectpath /tmp/exportedproject
tar czf /tmp/yourproject.tgz /tmp/exportedproject
scp /tmp/myproject.tgz youruser@remotemachine:~/dev
## Remote commands are in the right hand side, between ''
ssh youruser@remotemachine 'tar xzf ~/dev/yourproject.tgz'
ssh youruser@remotemachine 'qsub ~/dev/yourproject/script.py'
For this to work, you need of course to have a passwordless login, based on public/private keys, set up between your local and the remote machine.
If you need more than this, you can think of using Python's Fabric or the higher-level cuisine.