Version control and complicated applications that install files everywhere

Question

I have to work on a web application. The version control has directories structured like:

appname/conf
appname/www
appname/etc
appname/keys
appname/lib
...

However, for the application to work, it currently has to live in system directories:

/etc/httpd/conf.d
/var/www/html
/etc/appname
/etc/pki/tls/
/usr/lib/perl5/...
...

There is an RPM to take the VC'ed code and create a package that places the code into the production place (i.e. /var/www/html and others). There are no install instructions, I'm supposed to use the RPM and improvise (not ideal I know).

In a case like this, how does everybody edit the application, maintaining version control features (git diff etc...), and making changes to the app quick to be runnable? The app is written in Perl, so there's no compile step expected.

The ways I have thought of are:

• work on the VC'ed dir (and the code does not execute immediately, you have to have some install step)
• work on the code in the final location (so code edits immediately work, but you have to manually move code back to VC'ed dirs)
• write a filesystem watching program that watches changes to the VC'ed dir, and installs the changed files to their final locations (maybe something like this exists?)
• some other obvious method I've forgotton, I hope someone can tell me :-)

How does everyone handle cases like this?

Answer 1

I would be working on the code on a test server of some kind, but with the code in the correct locations. The version control then would need to be able to pick up the necessary files from their respective locations, but you don't deploy to the "final" location until ready (so that would basically be an "install" step, as you put it).

Since changing things to be more sensible may not directly be an option for you, is it possible for you to symlink from the system directories to the VC directory?

Answer 2

There is a difference between:

• version control: where you manage the source and build a delivery (can be in your case a tar.gz of all the files needed to be deployed in the system directories)
• release management: where you take a delivery and copy/deploy it in its running environment.

Some kind of Continuous Integration process (based on a scheduler like Hudson) can help you monitor the VC and build/deploy as soon as a new commit is made.