Skip to content


How Many Dev Environments are Enough?

Let’s start from the beginning. Grab a chair and gather around the hearth, you may wish to nod off at some point here.

We need to build a website so we set up the production environment for when the everything is done. Step one done. We then should really be working locally so we can build your site in a safe environment and have a nice deployment strategy for when things are done. Local development environment set up, that’s step two down.

Build locally then deploy the files to production. Easy. That’s enough to get going so let’s crack on!

Oh wait, we need to show someone the progress of the site. How could we forget about that! Silly us. In steps our staging area and our deployment process changes a little bit but we’re still good.

Build locally, deploy the files to staging area and then (after being OK’d) deploy to production. Nice.

How does that look in the branches of our project’s repo? Maybe something like this:

    - master (deploys to live)
        - dev (deploys to staging)
            - dev_branch-for-whatever (currently checked out)

A change is made to our current branch locally, we merge it in with dev, deploy to the staging site to test and then do the same again but merging and pushing to production.

This still seems ok, it just takes a little time with merging and what not. No problem though, the projects live and it’s almost finished! We just need to rework this last bit of functionality after some feedback…wait. We need to make a change to a previously OK’d page? But we haven’t finished the changes in the dev branch yet.

What’s that? We can’t push those changes up yet until the other bit has been done? Oh. OK then, I guess.

That messes up our branches a little bit as we’ve already merged the in-progress functionality into dev so we can’t branch from that. Crumbs. It’s ok though, we’ll go straight for a master HOTFIX and deploy straight to production then work the changes into dev later.

Oh crap, that changes we made to master have broken something else on the site. Another HOTFIX is on the cards. No worries.

Gosh dangit. The two HOTFIXes have caused conflicts with the dev branch. Ok, we’ll fix everything locally and then push it all back up so that master is good to go, dev is sync’d with master and the in-progress branch can resume as normal.

Right, enough of that.

So going for a local < development < production approach might not work as nicely as it sounds from the outset. But what is the alternative? Do we deploy to staging from the in-progress branch? What if multiple people are working on different branches, and therefore functionality and DB versions, of the same project? That would get messy faster than you could say 'Server Error'.

A possibility is to add another stage to the process, something like local < development < staging < production. Local and Development stay the same but you add in the Staging area as a buffer.

The production and staging environments are kept almost identical and the staging area is used to test any urgent fixes before pushing to production. The branch structure would look like this:

    - master (deploys to live)
        - staging (deploys to staging)
            - staging_hotfix (changes merged into staging and dev, when possible)
            - dev (deploys to development)
                - dev_branch-for-whatever (currently checked out)

Development and local continue as normal although, instead of dev merging into master, it merges into staging and then master only once it's been 100% signed off on the development server.

After all of that, you could just have a branch from master and throw caution to the wind to keep things simple.