: How to add version control and seperate development server to php/web development environment? I'm the team lead of a small group of developers. My background is primarily in application development

@Pierce454

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

Make your team familiar with:


Continuous Integration
Continuous Delivery


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.

Vote Up Vote Down

@Twilah146

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.

Vote Up Vote Down

@Vandalay111

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!

Vote Up Vote Down

@Shanna517

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.

Vote Up Vote Down