Web Development with Sphinx on a Virtual Machine for Shared and Dedicated Servers

Background

I am developing a web app with a standard LAMP stack. I am new to web development and had originally planned on simply FTP-ing my code (once completed) to my hosting provider (currently BlueHost, but may change in the future).

Sphinx Search

Recently, I decided to add advanced search functionality to my site powered by Sphinx search. Obviously this meant that I had to install Sphinx to my development machine. When it comes time for the site to go live I am going to have to install (via ssh) Sphinx on my production server. This could require a lot of time debugging subtle differences in the development and production installations of Sphinx (and the rest of the environment for that matter).

I'm Still Learning

I have stumbled upon virtual machines and it looks like (correct me if I'm wrong) some developers create VM's for each project and load the VM onto their production server. This keeps them from having to debug their code once it is uploaded to their production server, thus, increasing the probably for success.

The Question

My question is this: Would it make sense to develop on a virtual machine and attempt to load that onto my production server when app development is complete? If so, can this typically be开发者_如何转开发 done for shared servers or only for dedicated servers? If not, would you mind explaining what your opinion of the best way to solve the potential problem of having differences between your development and production servers.

Most shared servers have very limited permissions. Some might not even allow you to run sphinx let alone a VM instance in your server.

The usual process is that you have 3 servers/environements (ideally 4 would be nice).

1. Development server - This is your local working machine and you on this machine. This can be on a completely different environment than your production server.

2. Staging server - This server should ideally be an identical copy of your live server. This server usually contains an unstable version of your application with all the latest commits on it. Having your staging server be as close (system wise) to your production server will help you identify and solve environment issues before they arise to blindside you on the production server.

3. Production server - This is your live server. Once you have a stable version on your staging server, you'd simply deploy the code base to your live server. This is where having your production and staging servers identical to each other helps as you don't need to worry about environment differences messing things up.

Additionally, you could have a mirror of your production server to debug any environment/data specific issues.

If you're running on a shared server, it's best if you have two domains setup with your web application. Have something like http://beta.webapp.com on your server and use that as your staging server.

I can't comment on VMs, I haven't used them on a production system in the way you describe but it would amount to the same thing I think.

JohnP covered a lot of ground. I would add that you could take a look at VirtualBox. It's free and works very well in my experience. It should let you run a VM configured however you choose, for example, exactly like your deployment host.