Question

We are a small team of 4 developers working on a web application. We use trac+svn on a shared server for version control and ticketing and we are happy and satisfied with this. The same shared server also hosts our web application. The application itself is a Perl CGI application that uses CGI::Application and a moderate number of standard (CPAN) and custom Perl modules that are installed in the usual (/usr/lib/perl…) and a few unusual locations (/home/user/lib/perl..). While the broad details might be irrelevant, the most important point is that the location/layout of libraries on our development machines is different from that on the production (shared) server. We have to live with this as a given. The library layout is identical on all development machines though.

Here is a typical, but clearly sub-optimal work-cycle that my colleagues and I follow:

1. Code and test on development machines
2. Checkout/Commit/Update our code onto the SVN
3. Periodically “svn export” onto the appropriate DocumentRoot of the server
4. Hand edit the exported tree to set the library includes match the library layout on the server
5. Test application on live server, raise tickets for each other
6. Go to 1

Clearly there must be a better way and would appreciate hearing from others who might be handling this better than we are. For example is there a way to svn export and fix the library locations in an automated way? Or is there some completely different way to handle this situation than we have been doing so far.

Thank you for your attention

Answer 1

You should have scripts that do this for you that can be run from a local box. Mine always look something like:

$> checkout from source or copy from working
$> run sed/perl -pi/copy to convert configs to the production values 
     (ie cp production.config myconfig)
$> upload to web server (rsync/ssh/ftp/etc)
$> ssh $SERVER migrate_db, set permissions, run unit tests, etc

The last one requires ssh access which I always look for but everything else can be done locally. You’d usually have a set of dev configs and a set of production configs (or a script to convert from dev to production

One step uploads are always a really good idea.