Each developer, and each system gets its own config file, which are kept under version control.

When you run the build script, you must tell it which system to build for, and you *can* tell it (optionally) which developer’s config to use. The developer’s config values override those of the environment, so that they can have their own paths etc.

Makes switching ‘environments’ quick & painless.

That way the cli-version of the application will also have that environment variable set, it works in shared hosting setup’s and it’s real easy to implement
[code]
if (is_readable(dirname(__FILE__).'/system.id')) define('SYSTEM_ID', trim(file_get_contents(dirname(__FILE__).'/system.id')));
else define('SYSTEM_ID', SYSTEM_ID_DEV);
error_reporting(E_ALL);
switch ( SYSTEM_ID ) {
case SYSTEM_ID_LIVE:
error_reporting(E_NONE);
break;
etc etc

There’s only a few targets available but it could get improved easily by adding a custom target function or other useful targets, like yours.

So far it’s been working perfectly using the host target, I just have to svn update on any of the dev/prod/test/.. servers/laptops/… and it’s working. You can even use different configuration variables for different development environment if you wish. No “multiple servers in a prod environment” tested yet, but since the prod environment settings are the default ones in my files, that wouldn’t be a problem.

Interesting way of doing it, and probably better suited to a multi-developer environment than my method is.

I’d usually use the trunk for the production environment. This way a normal deployment script including an export from the trunk would operate on the production files only.

Then I’d create folders as branches in the SVN for each additional environment, e.g. dev, staging, etc. Normally I’d name the environment folders after the hostnames the would be deployed on. This gives the additional benefit of having specific environment folders for different members of the development team, should they need to have specific settings, etc.

The resulting SVN structure would look something around this:

SVN
|_trunk
|_tags
|_branches
|_environments
|_development
| |_app
| |_config
| | |_database.php
| | |_core.php
| |_webroot
| |_files
|_staging
| |_app
| |_config
| | |_database.php
| | |_core.php
| |_webroot
| |_files
|_john.dowe
|_app
|_config
| |_database.php
| |_core.php
|_webroot
|_files

As soon as a new environment is needed, or an additional developer is added to the team, we create a corresponding folder under branches and add under it it just the environment-specific folders – like database settings and other configuration, plus a folder for any user-uploaded content. Then the new developer would checkout the trunk and in their working copy would switch just the env.-specific files – to the ones under their respective folder under branches/environments.

This setup allows for both – having everything (environment specific configuration files, plus user-generated content, like uploaded files, etc.) under version control, and not overwriting each other’s settings.

Then if someone needs to modify the configuration (e.g. add a new environment-specific setting, may be an SMTP server name), they can propagate the modification through to all other environment files, so all other members of the team would get it when they update their working copies.

For projects in which I’m the only developer, I’d just have folders for each environment. I normally don’t care if my staging version is a working copy, so on the staging server I just checkout the trunk and switch only the staging-specific environment files. Then the normal working cycle wold be to work on development box, from time to time update the working copy on the staging environment and let the client preview the functionality, then finally export the trunk (which represents the production specific code) and upload it via SCP or FTP.

This might look as a slightly complicated setup to maintain, but once you’re used to it it proves quite useful. At least for me.