Why multiple environments?

Why we use at least three environment tiers for all of our projects, even CMS work.

Ten years ago when I started out as a developer I learned the downside of working directly on a production environment. My first job was as the office’s “computer guy”: basically meaning I did all of the website programming, server configuration, and fixing office computers. I was the only one who knew anything about our system and I didn’t answer to anybody. I had 100% freedom to do things how I wanted to do them. Pretty great right?

Not really.

The process I used to develop would involve opening a text editor, taking a file on our server, renaming it to something like “<file>_dev.” Deploying was removing the “_dev” when the feature was ready.

This was a recipe for disaster, one night on Friday I deployed a feature I was working on which silently broke a large amount of critical functionality for the site. On Monday my boss and I rolled into hundreds of angry emails from customers who were running into this error.

I didn’t have a mentor telling me about things like source control, testing and the development cycle. I thought my “process” was working until it failed miserably. Fortunately I didn’t lose my job but I did have to spend a few days fixing the issue and then emailing every customer with a personalize apology. Believe me, nothing humbles you more as a developer than having to write a hundred personal apology emails.

That’s why it pains me whenever I see a project where updates are made live on the server. I see a lot of freelancers start by developing the site locally, then FTP everything up to the server for launch, then maintain the site on the server. Every time I see this setup I know they are one step away from disaster.

I think a lot of freelancers work this way because:

– They’re focused on the initial build of the project: “Let’s just get it launched” instead of the maintenance afterwards
– It’s seemingly faster, more straightforward. Why configure and copy everything three times instead of once?
– Most CMS platforms don’t support multiple environments internally and don’t have great documentation on how to set one up properly

However you lose a lot of advantages / time saving tools if you work only on the server:

– No source control, code tracking. It becomes lot harder to track your updates without it.
– Clients can’t test features before they’re “live”, it’s all up to you to verify things work the first time.
– It’s harder to bring on additional help, likelihood of overriding each other’s work goes up.

So let’s talk about what a three tier environment looks like. It should consist of the following tiers:

Local: Everyone working on the project should have their own copy of everything needed to run the software on their own machines. The client does not have access to this environment and is subject to change constantly.

Stage: This tier is for client testing and approval and should be accessible to the client. Can also be used to do integration testing of multiple features. It does not share any code, assets, or data with production or the local environments.

Production: The live/public site, only features that make it through client testing and approval are allowed in this environment.

The idea is that a feature doesn’t make it up to production until it passes through the “stage” tier and at least goes through a round of testing and validation. For each tier to be properly configured they must have:

– Identical structure: each environment must have the same folder and file structure relative to their public directories

– Isolation: each environment must exist in their own folders separate, for example “stage” should not be a subfolder of the production environment (http://mypublicsite.com/stage)

– Each environment should have their own separate database and user assets, although data can (and should) be regularly copied down from production and used to refresh the other environments

– Environments shouldn’t store the configuration information in the same place. Each environment should know where to look for their configuration information and shouldn’t require changing every time a deployment happens.

Setting up a multiple environment configuration for a lot of CMS platforms can be a challenge as a lot of CMS systems don’t support having separate configuration settings for each environment out of the box (the exceptions I know are Craft and Pyro). Fortunately there are ways to do it in just able every CMS and I’ve written a few guides to get you going.


How to configure multiple environments in Magento (and nearly any PHP project) using symbolic links

How to configure multiple environments in ExpressionEngine using FocusLab’s Master Config

How to configure multiple environments in Codeigniter

How to configure multiple environments in WordPress (not written by me, but very good!)

How to configure multiple environments in Craft CMS (From Craft’s docs)