Dev / staging / production INI settings files strategy

Overview:

In almost every project we have a small number of settings files that have important differences on the production host versus development or staging hosts. This problem is made serious when the settings are in your version control system.

The resolution is trivial: Create a version of each file for each context that needs to be customized, eg site.ini.append.php_PRODUCTION, put this in SVN, and create a symlink with the name that eZ Publish is looking for.

In detail:

Suppose that you have a project that exists on a production host and your development host.

Suppose also that the only difference between the two code-bases is in settings/override/site.ini.append.php

1/ Create two versions of the file:

settings/override/site.ini.append.php_PROD
settings/override/site.ini.append.php_DEV

2/ Remove the correct file:

rm settings/override/site.ini.append.php
## maybe, svn delete settings/override/site.ini.append.php ... etc

3/ Create the symlink (for example on production):

cd settings/override
ln -s -T site.ini.append.php_PROD site.ini.append.php
## note that on windows you should use mklink and that this syntax might vary depending on your *nix

4/ Don't commit the symlink to your version control, eg for SVN:

svn propset svn:ignore "site.ini.append.php" .
## and commit this

Now, you can safely update your production instance without risk of pushing development settings.

There is still some work to maintain this: Settings changes that occur over multiple instances have to be done over multiple files.