I'm creating a web application having a standard Light stack. I'm a new comer to web design coupled with initially intended on simply FTP-ing my code (once completed) to my host company (presently BlueHost, but may change later on).

Sphinx Search

Lately, I made the decision to include advanced search functionality to my website powered by Sphinx search. Clearly this resulted in I needed to install Sphinx to my development machine. When the time comes for that site to visit live I will need to install (via ssh) Sphinx on my small production server. This might require considerable time debugging subtle variations within the development and production installations of Sphinx (and also the relaxation from the atmosphere for your matter).

I am Still Learning

I've happened upon virtual machines also it appears like (correct me if I am wrong) some designers create VM's for every project and load the VM onto their production server. This prevents them from needing to debug their code once it's submitted for their production server, thus, growing the most likely for achievement.

The Question

My real question is this: Wouldn't it seem sensible to build up on the virtual machine and try to load that onto my production server when application development is complete? If that's the case, can this typically be accomplished for shared servers or just for devoted servers? Otherwise, can you mind explaining what your opinion of the easiest method to solve the possibility problem of getting variations involving the development and production servers.

Most shared servers have limited permissions. Some may not even permit you to run sphinx not to mention a VM instance inside your server.

The typical process is you have 3 servers/environements (ideally 4 could be nice).

  1. Development server - Here's your local working machine and also you about this machine. This is often on the different atmosphere than your production server.

  2. Staging server - This server should ideally be the same copy of the live server. This server usually consists of an unsound version of the application with the latest commits onto it. Getting your staging server be as near (system smart) for your production server can help you identify and solve atmosphere challenges before they arise to blindside yourself on the development server.

  3. Production server - Here's your live server. After you have a reliable version in your staging server, you'd simply deploy the code base for your live server. This is when getting your production and staging servers just like one another helps as you don't have to be worried about atmosphere variations playing some misconception.

Furthermore, you might have one of the production server to debug any atmosphere/data specific issues.

If you are running on the shared server, it's recommended that you have two domain names setup together with your web application. Have something similar to in your server and employ that as the staging server.

I can not discuss VMs, I've not used them on the production system in the manner you describe however it would add up to exactly the same factor I believe.

JohnP covered lots of ground. I'd add you could have a look at VirtualBox. It's free and is effective in my opinion. It will allow you to operate a VM set up nevertheless, you choose, for instance, the same as your deployment host.