Ever had this problem? You were so excited to see, if some piece of code works on your live system, that you forgot to change database access configuration and file paths? Probably not, because we’re all respected professionals here *wink* and the case is usually: it’s 10pm, still at the office and x product is launching tomorrow and you accidentally overwritten the configuration, because you didn’t have time to finish the deployment script :P. Or maybe you have to deploy your application to even more than two machines? Well, here’s a small cheat sheet.
The lazy way
switch (php_uname('n')) {
case 'livedevhost04':
$dbhost = 'sql.example.com'; $dbuser = 'myapp_user';
$dbpass = 's7d6y3726ye86'; $db = 'myappdb';
break;
case 'Mateusz-Laptop.local':
$dbhost = 'localhost'; $dbuser = 'root';
$dbpass = ''; $db = 'testdb';
break;
default:
echo 'No configuration found for host: '.php_uname('n'); exit;
}
This way is quite nice for most scenarios. Very convenient. Get the machine’s hostname, add a “case” to the switch with server’s configuration and you’re good! If you’re deploying through some sort of SFTP/WebDAV protocol, you can easily upload files without any additional modification before running the script. The same with deployment techniques like Deploy using Git.
The only problem is that you’re slightly exposing configuration settings for all your boxes. If you don’t feel comfortable with this, try a different technique like symlinks to a local configuration file.
Personally, I use it quite often. It’s better and way less annoying than swapping commented settings.
The ‘bash’ way
This can be used for many different scenarios. Not just files, but also directories. Here’s a very nice and readable script for symlinking stuff based on local hostname:
#!/bin/bash
targetfile=webroot/config.php
fromscheme=webroot/config._HOST_.php
fromfile=${fromscheme/_HOST_/`hostname`};
if [ -e $fromfile ]
then
rm $targetfile
ln -s $fromfile $targetfile
echo $fromfile == $targetfile
else
echo [ERROR] Local configuration file not found: $fromfile
fi
Additionally, you might want to execute a custom script that will do something for you after retrieving a configuration set.
Notice the “webroot/”, please keep sensitive scripts outside your document root, mkaay? Maybe even clean them up after deploy and keep them in repo!
You’re only in trouble, if you don’t have access to a bash shell on your hosting server (use first method) or you’re running Windows (you can try cygwin if you’re mad enough ;] )
A JavaScript Bonus
You’d be surprised how many times, I almost did something very silly on a deployed version of an ajax based application. As a bonus, here’s a script you can put in your app, to help you identify, which build you’re currently working on. Especially useful, when running on iOS in web app mode.
<div style='display:none;color:red;' id='devnotification'>TEST SERVER</div>
var currentHost = location.href.split('/')[2];
if (currentHost == 'localhost' || currentHost == 'dev.example.com')
document.getElementById('devnotification').style.display = 'block';
Enjoy! And remember to run your tests kids!