I'm the team lead of a small group of developers. My background is primarily in application development and I've worked in larger groups where version control (SVN, Git, etc.) have been used and proven very useful. I'm starting to oversee our web development, which is currently one lonely php developer, however, we will be adding a second php/web developer soon. Currently our lonely php developer programs things live (ie: he makes changes to a php file, uploads the new code, and sees what happens). I'd like to change this since this is just asking for a disaster to happen. I'm also thinking of adding some sort of version control to his process. We already have a SVN server being used for application development so I'd like to leverage that somehow. I'm looking for advice on how best to approach this and what kind of changes to make.

Should we use our existing web server for development? We could make a complete copy of the existing websites and have these copies sit on subdomains. We then make changes to these copies and if everything went OK, we synchronize the subdomains with the main sites. If this is a good approach, what set of tools (ie: software) would be best to use for the synchronization? Is there any software that could also commit these changes to the SVN server while synchronize things on the web server? The less steps are involved in these changes the better.

Or would it be better to have a completely separate server for development? The downside of this is maintenance ... we're short staffed as it is.

Any and all advice is highly appreciated. Web/PHP development is a bit different than your standard application (Java, C++, etc.) development that I'm used to so I'm definitely open to idea on how best to run this department.

Thanks, Harry

  • 1
    Don't produce dupes on different sites - question can be migrated, if it will be needed Feb 6, 2013 at 5:33

4 Answers 4


NEVER ever work on the production server and "see what happens".

Make your team familiar with:

and hand out (send out) everyone a copy of this book which I highly recommend: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

Automate as much as possible. Trigger tests, linters, builds without effort. Create virtual environments for development, staging and production. With virtual environments you can test completely new scenarios as well as mimic your production server (Search, for example, for "virtualbox headless", read articles like this one). Once set up, it really ads no complexity as you orchestrate every step with the click of a mouse or the next commit.

In the context of Delivery there are lots of tools out there that help automate things, be it Capistrano or Fabric (Python) or of course Jenkins (Java).

There is no one size fits it all approach (read the book), but your team will refine the process step by step.


My team is in the same boat, and our solution was to create a local development server with the exact same configuration (apache conf/php.ini/versions) as our deployment server, and use SVN for version control as we would for traditional app development. Our development server also handles SVN+Bugtracking systems, so it's much easier to handle bug/feature requests. Since the development and deployment servers are identical in configuration we only get transfer errors during deployment.

  • I would second this post except that I would use git over SVN. Having used both, I will never go back to SVN again. Feb 6, 2013 at 11:42
  • I agree with Stephen, if a choice would have been possible I would have preferred GIT as well, but it was a pre-GIT install, and since then nobody took up the task of migrating the projects...
    – Meki
    Feb 6, 2013 at 15:19

You have to decide for yourself whether it's worthwhile to have a separate staging/testing server just for development.

As for what tools you can use, there are a lot of CI tools and deployment automation tools out there that work with SVN. Capistrano is a pretty light weight tool that requires Ruby knowledge, but using it you can deploy/configure apps on multiple servers pretty easily. It's also possible to write a Capistrano recipe to automatically deploy to the staging server when a new commit is made (with an SVN commit hook), then automatically run functional tests on the staging site afterwards, and then if the tests succeed, automatically deploy to the production server.

Using Capistrano, you can also easily roll back your staging or production server to any previous version you want as well as automate other tasks (e.g. backing up the site or other maintenance tasks).

However, some trouble I've had with this sort of setup is that to simplify things, I've needed to use a symlink for the site's webroot due to the way Capistrano stores revisions and keeps track of the active revision. Unfortunately, Apache sometimes caches the symlinks somehow, so you have to do some ugly hacks (like delete the symlink, use wget to trigger a server error, then recreate the symlink) to get the changes to be reflected immediately.

If you can change the webroot to the actual current version path, that might avoid the problem, but you'd need to restart the web server each time (if you have access). The alternative is to use .htaccess and mod_rewrite, which might be less work.

  • I would never use a seperate development server. As, from my point of view, it will add extra complexity in deployment to live server. Moreover, as they are different servers, behavior may changes after live deployment, making another disaster.
  • Sure, I will strongly recommend to use some version control system. My preference is "GIT", independent of any programming languages.
  • I guess, you are using a VPS/dedicated server, so that you can setup the version control server yourself.
  • I have experience in using development server and sync with live applicaiton, its very easy and efficient. you will always work on your local environment. After its working, commit/push to development branch. test it on a subdomain(like dev.yourdomain.com, with basic htaccess authentication so that google doesn't crawl it). after its tested properly, just merge the development branch with master(live) branch and push, and its DONE!
  • 1
    Your first and last points seem to contradict each other?
    – MrWhite
    Feb 7, 2013 at 10:25
  • no actually, I meant different branch of a single repository on 4th point, not different server.
    – Rana
    Feb 7, 2013 at 11:25

Not the answer you're looking for? Browse other questions tagged or ask your own question.