I usually write my code, either java, python or c++ in eclipse on a laptop or desktop computer. Eclipse is very comfortable, but unfortunately too large to run on these small target systems.
So I had the need to deploy the code to a remote system.
Deployment can be done manually, when a few files are transferred by a ftp tool.
But when complexity gets larger (omit some files, different target systems), or frequency of deployment is high (many per day), automation is needed.
Apache ‘ant’ is a scripting tool which allows to package, transfer and remotely deploy software.
Ant from ant.apache.org is a build system based on a xml syntax, which aims to run on almost every operating system where java is available. It is widely used in professional software development in industry.
Eclipse comes with ant preconfigured, at least if you download the java edition and then add the c or python or whatever plugins.
In all my projects, an ant build file ‘build.xml’ is in the project root. There I provide targets for version control, backup and deployment. See here a snippet from the build.xml for my scratchClient. The detail is about deployment here.
<project name='scratchClient' default='distribute'>
<!-- build.properties provides connections and passwords -->
<property file='../build/build.properties' />
<!-- filesets define 'what' to transfer -->
<fileset dir='../' id="tar.fileset">
<include name='scratchClient/**/*' />
<!-- in some configurations, there are phone numbers, pin or alike, exclude from deployment */
<exclude name='scratchClient/**/private/**/*' />
<exclude name='scratchClient/build.xml' />
<exclude name='scratchClient/build.properties.template' />
<exclude name='scratchClient/*pid' />
<exclude name='scratchClient/**/*pyc' />
<exclude name='scratchClient/build.properties' />
<exclude name='scratchClient/download/**/*' />
<exclude name='scratchClient/temp/**/*' />
<exclude name='scratchClient/.settings/**/*' />
<exclude name='scratchClient/.project' />
<exclude name='scratchClient/.pydevproject' />
</fileset>
<target name='deploy'>
<echo>deploy to ${pi.host}</echo>
<echo>from ${basedir}</echo>
<delete file="download/scratchClient.tar.gz" failonerror="no" />
<tar destfile="download/scratchClient.tar.gz" compression="gzip" >
<fileset refid="tar.fileset" />
</tar>
<echo>send app code /home/pi/scratchClient ${pi.user}@${pi.host}:/home/pi</echo>
<scp file="download/scratchClient.tar.gz" password="${pi.password}" todir="${pi.user}@${pi.host}:/home/pi" trust="true" />
<sshexec command="rm -R /home/pi/scratchClient/*"
host="${pi.host}" username="${pi.user}" password="${pi.password}"
trust="true" failonerror="false" />
<sshexec command="tar zxvf scratchClient.tar.gz"
host="${pi.host}" username="${pi.user}" password="${pi.password}"
trust="true" failonerror="true" />
</target>
The script packages the code in a temp folder (not adding some common stuff). Then it sends (scp) it to the target machine, wipes the target folder (sshexec) and unpacks the data there. sshexec is connecting to the remote computer and executing commands there.
In eclipse, this script is activated by a rightclick in an outline view, but can also be activated on a eclipse build procedure.
The host names, passwords for the target environment is in another build script build/build.properties
One reason is that these are common for many projects, the other is that these are outside the usual scope and when copying a bunch of data and sending them away these security related things will not be included.
This file looks like:
#Sun, 17 Mar 2013 08:33:21 +0100 pi.host=192.168.2.105 pi.user=pi pi.password=NNNNNNNNNNNNNNN root.user=root root.password=NNNNNNNNNNNNNNN
This is a complex setup, but reliable and I have full control on what happens.
Except for a ssh-access on the raspberry pi, there is no extra deployment software needed.