We recently migrated Where’s it Up to our fancy new hardware, it took a bit more effort than planned (some pains surrounding our use of MongoDB) but I’m incredibly happy with how things have ended up. As mentioned earlier we’ve purchased our own hardware, and have racked it with Peer 1 here in Toronto. We’ve installed a hypervisor, and are running different VMs for critical services: MySQL, Mongo, Web Production, Web Development, etc.
Our websites sit under /var/www, so Where’s it Up resides at /var/www/wheresitup.com/. Under that directory we have /noweb/apache/ which contains both wheresitup.com and dev.wheresitup.com, configuration files for apache. The entire /var/www/wheresitup.com directory tree resides nicely in our version control system. We hand off key configuration options to our websites through the use of Apache’s SetEnv, things like SetEnv mysql_host dev.mysql, these apache configuration options represent the only difference between the two code bases.
I’ve written or maintained code that implied the state (Dev/Production/Stage) based on the Host, directory, or other factors in the past. I much prefer grabbing an explicit constant. It feels cleaner, I don’t have to read up on which variables could have been manipulated by an attacker, and I can ask the exact question I want answered: Is this dev, rather than “is the url the one that means this is dev”.
This allows us to match our Development and Production virtual machines very closely, the only difference between the two is which apache configuration file is sym-linked under /etc/apache2/conf/sites-enabled. Clearly WebDev links to the dev.wheresitup.com file, and WebProd links to wheresitup.com. We actually cloned one machine to produce the other.
Keeping the configuration files so close also makes a lot of sense to me. If I’m adding a new constant on Dev, the immediate presence of Prod reminds me that I’ll need to add it there as well. Storing the entire site: PHP code, supporting apache configuration, etc, all in once place makes it easy to avoid forgetting anything (which is easy when it's a different file on a different server). The only exception is SSL certificates. We currently host a number of our projects with GitHub, and trust them as we might, we’re not willing to hand those to anyone else.
Comments »
When I've simply configured a setting like dev/stage/prod I end up putting a series of case structures in my code. If DEV then set mysql, password, etc. That works, but I've never been to happy with it. Under the current structure the code doesn't care if it's Dev/QA/Prod, it just blindly uses the specified database, not knowing if it's the Prod one or Dev. Luckily related systems like Stripe also provide Dev tokens, so they don't require special handling.
Where we're using gearman we're running it on the webserver. So in both cases our code just pushes it to a local instance. Our worker pools have separate configs for Dev & Prod, so 50 prod workers connect to the prod gearman, and 5 dev workers connect to the dev one.
AllowOverride FileInfo AuthConfig Limit Options
to easily modify the settings in the .htaccess file.
Jsut curious.
I'm using the same approach except the variable have a broader name "ENV_TYPE" which can be prod/dev/test.
Also, what does that variable default to?