Setting Up A Proper Development System

By Michael Kramer on October 3rd 2014 @ 9:16 am

The process of “going live”

One of the hardest things for me to do has been setting up a proper development tree. This post is not about setting up a development environment, but more setting up a proper process of pushing things live, and being able to work on a development server without messing up the live site.

For large clients, I like to have 3 separate domains., and

These 3 links each have different roles.

This site is where you can screw around and do all that you do in developing. You can break the site, you can add new modules, you can revamp the code. You and the other developers on your team are the only ones who have access to this server.

Password protect it if needed, but most important, add a robots.txt to it with:

User-agent: *

Disallow: /

This will insure that google and other search engines who for SOME reason might crawl, will not index this site. It will be invisible. This site you should never send for outward review.

This is the site where you merge your doings from the dev site, to the current live server. The process for the staging server is to get everything ready to push to the live server. As with the dev site, it should have it’s own code base, and it’s own database. The database should at first mimic the one on the current site. You should copy over the database from the live server to the staging server and begin your work.

Once you get this site up and running and working perfectly for you, with all the latest data from the live server and all is well, send off the link to your Quality Assurance team for further testing. No matter how thoroughly you test something, I promise you they will do something completely “stupid” and mess up something you could not have even dreamed of.

Once it passes through the QA and get’s an OK go status, there is an additional step that needs to take place. You need to put a maintenance message on the old site and shut it off (I suggest these big changes happen in the wee hours of the night). You then need to copy the live database over to the staging server once more, and do one more round of testing your self. Onces approved you push all the new code to the live server, do any database updates that you need to (adding of additional fields etc) and voila! It’s pushed live.

Remove the maintenance message, and monitor it for a few days to see if anything goes belly up and you need to do a quick fix.

Important Note: Always remember to backup and keep a few different working iterations of the site, you never know when what you did will have a cataclysmic chain reaction that causes everyones data to blow up :)

comments powered by Disqus