tl;dr: Add “.production” file to the root folder od your codebase on production servers, add “.development” file to the root folder of your codebase on development servers (both files empty, only name is important), ignore them globally in your git repo, ignore them locally in your FTP settings or whatever you’re using to push changes up to your servers (I’m using ST2+FTP plugin for dev server) and add the following somewhere at the top of your index.php file:
Now, you can put all settings for both production and development environments in your configuration files and choose the right one based on your ENVIRONMENT constant! Sweet, one less thing to worry about!
Long version
How do you deal with differences in your codebase between production environment and development environment?
In my case, I used to have my codebase in git set to production (disabled error displaying, live base_url, live database, all functionality enabled) and using git’s “ignore locally” feature several files changed so that error displaying is enabled, base_url set to dev server, dev database details, emails redirected to phpconsole.
What’s wrong with that approach? Quite a few things, actually. What if a new developer sets up his account on dev server without changing any config files and starts running his code against live database? Well, we can change the repo to point to dev db by default. But what will happen if someone deploy code to one of production servers and forget to change values to point to the live db? Oopsie, some of the clients are hitting our dev database!
One day I was wondering how to make it all work automatically and remembered that Beanstalk uses “.revision” file in root folder of your codebase to track which revision is deployed to your servers.
I thought “brilliant!” and decided to use similar approach:
The snippet of code from tl;dr above sets ENVIRONMENT constant that can be used to change your application’s behaviour. If none of environment files is present, the page will exit with an information about what happened. This way we’re mitigating risk of running wrong version of the code,while keeping convenience of single codebase.
Of course, you’re not limited to only 2 options, you can easily add another one, e.g. “.staging”.
Let me know what you think about this approach in the comments below.
You can also read:
How to understand half of Harry Potter book in any given language
How to increase productivity per square inch of your screen
Logging in with QR codes
Posted 2 months ago
-