Setting up a development server

Question

When developing PHP applications, it's best to have a server you develop/test on, and then a live server you put everything once it's ready.

OK, but how?

If you are hosting through a hosting company how can you setup your own development server to test on that mimics all the LAMP settings as your live server? Because if they differ then testing on one that isn't identical to the live one, defeats the purpose right?

Is it better use another server through the same hosting company and ask them make both the development and live ones have the exact same settings?

Also what is the best work-flow to use to check files out from "live server" work on them in the "development server", then check them back into the live server?

Thanks!!

Answer 1

Two points from my daily work:

• XAMPP is your one-stop shop for setting up a Apache/mySQL/PHP stack on Windows. I develop with it and deploy to Linux machines, no problem.

• If you want to set up a Linux environment on a home server or virtual machine, I asked a question a while ago that may interest you: Pre-installed Linux for Web Developers?

Is it better use another server through the same hosting company and ask them make both the development and live ones have the exact same settings?

If you can afford a second server, it may well be the best way to go. On the other hand, a local machine you could upgrade and fiddle around with at will, and all that at a fraction of the long-term cost of a second rented server. If in doubt, I would go for a local machine.

Don't forget PHP is a very portable language. If you don't use any specific command-line tools or totally exotic extensions, making a PHP application work across Linuxes, and even on Windows is a question of some settings and details, but not really a big deal any more.

Also what is the best work-flow to use to check files out from "live server" work on them in the "development server", then check them back into the live server?

There are many, many opinions and practices in this field. For me personally, the following workflow has turned out to be ideal wherever I've used it - I am still in the process of implementing this myself in all projects and for all clients.

1. Edit files locally in IDE

2. Upload to development server via built-in FTP function of IDE

3. Test on development server

4. Once a feature is tested and works on the development server (i.e. it's "finished"), check the whole package into a Subversion (or other) repository

5. On the live server, have a build script check out the latest revision from the repository, download it to a directory with the revision number, and when finished, change a symbolic link that pointed to the previous revision to the latest one.

That way, every change you make to the live environment is logged in the version control system, and reverting to the previous revision is a question if seconds. To me, this was a huge relief compared to working with pure FTP everywhere.

Possibly also interesting question: Setting up a deployment / build / CI cycle for PHP projects

Answer 2

You can check all the production server's setup via phpinfo() and copy them on your development environment, no need for them to be on the same provider.

I usually commit the code to source control, and checkout in the production environment, hiding all the repository information via .htaccess, for example, see here.

Another (less recommended) option is to just have your master source in the development machine, and once it's ready FTP it up, there are various free tools that will only upload changed files.

Answer 3

As for the server side, you have multiple possibilities. You could use vHosts when you have Apache, with two different DocumentRoots: one for the live version, and one for development. Or you can have the development environment on your local machine, and then the live (+ staging) on your dedicated server / webspace whatsoever.

In our current project we have a three-tier system:

development, staging and live. Staging and live are really almost the same, so that I can eliminate any problems when rolling out from dev to staging. It gives me another security layer before rolling out to live and eventually noticing that something went wrong.

Considering the workflow for rolling out, you should create an application config, where you can define several application environments (development and production) that automatically choose their environment based on URLs, defined environment variables or something else. So, in Zend Framework for example, this configuration driven behavior is built into your applications. In your config.ini file, you have a template which looks like this:

[production]

[staging : production]

[testing : production]

[development : production]

In there you can define different options for, lets say, your database connection i.e.

So when you check your changes on the dev machine into subversion and do a rollout onto your live system, you do not have to change the configuration. It should just work.

Answer 4

As far as workflow goes, that's typically what happens for small sites. Depending on the size of the project, though, it might be a good idea to use version control like Git or Subversion.

Answer 5

You don't need to go anywhere near as far as asking a hosting company to setup two identical hosting environments for you. The majority of the time they have up to date versions of php, mysql and apache. I develop on a Linux machine, that has a lamp stack setup already, so my workflow is pretty seamless, and I use a svn with post-commit hooks to upload to the live server. If you are worried about incompatibilities between you're 'dev' server and the hosting server, the easiest thing to do is make a phpinfo file,

<?php phpinfo(); ?>

and check that your hosting server does not prohibit any special functions you use on your dev server (and this is pretty rare that the hosting company blocks vital things, and if they do you can easily send support an email and 99% of the time they will assist you in enabling whatever particulars you require. But as far as setting up your dev environment, I would go down the track of grabbing virtualbox, and installing ubuntu, find a tutorial for making ubuntu a web server (seriously only a few apt-get commands) and you will be smoking with gas !