0

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.

ServAce85
  • 1,602
  • 2
  • 23
  • 51

2 Answers2

0

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
  • 49,507
  • 13
  • 108
  • 140
  • Great explanation, but that still leaves me with a few questions. If you suggest that most web apps are deployed using dedicated servers, then why do I read about all of these Fortune 500 companies using cloud hosting services such as RackSpace and Amazon's cloud? I understand that it's for on demand processing/bandwidth/etc., but how do they produce a consistent, bug-free result (keeping in mind what you've told me above)? Thanks! – ServAce85 Jun 22 '11 at 07:18
  • @ServAce85 you still have a dedicated server, that's usually the start point. From there you basically distribute the load to your CDN or EC2 instances. A VM is still an environment, so they'd just install those same environments on their development machines. The environments won't be radically different. The problem here would be for you to duplicate the environment that your hosting provider gives in your local machine. This is a non issue for others since they are running their own servers and have control of the VM themselves. – JohnP Jun 22 '11 at 07:27
0

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.