Subversion and environmental specific configuration

On many projects I work with, whether they are websites or J2EE applications they need to connect to a database. The configuration of how your project connects to a specific database is just one example of where your source code needs to be environmental specific.

This causes a problem when developers commit configuration files specific to their development environments. At sites where multiple releases of projects are happening to many separate environments it is only a matter of time till the release is using the wrong database to connect to. At the very least this will invalidate some of the testing which has been done, at the most it can make for a embarrassing customer experience with your product.

The method I use to prevent this happening is to not commit the actual configuration files when at all possible. But instead to commit the file renamed to something similar. This seems to be becoming more standard as I see more and more open source projects following the same sort of process.

For example a developers “config.php” my contain the following strings to make a connection to my MySQL DB.

Config.php

<?php
$host = "my_dev_host";
$user = "my_dev_user";
$pass = "my_dev_password";
$database = "my_dev_database";
?>

This is fine as the developer progresses with adding features during alpha and beta stages. But when the code is ready to be tested, it will often connect to a different database. Testers often have set test data worked out before hand.

A good practice for configuration like this would be to rename the file to config.php.template, and to store this under version control.

Config.php.template

<?php
$host = "xxxxxxx";
$user = "xxxxxxx";
$pass = "xxxxxxx";
$database = "xxxxxxx;
?>

As part of the installation or setup stage of the product being renaming this template to its proper name, and to correctly configure the variables inside.

This has a number of benefits, firstly as a environment is updated with the latest release the configuration file is not overwritten as it is not specifically in version control. It also reminds the installer to specifically check the configuration file as the application will not work as is, and needs modified.

< ? picture ? >

This is a small price to pay to ensure that there is no confusion between environments.