Setting up a development environment to mirror production

Peter B

I am looking to set up a development environment to mirror production.

On our production environment each application is run on a different server. To save the cost of VMs we want to run many of the apps on the same server on our development environments. These environments will not be used for performance / load testing.

One hurdle we have come across is deciding how to deal with our PHP and static content. On production we have a PHP server which serves up dynamic content but we also have a static server which provides static content such as HTML, JS, Flash and images. The static server does not run php.

Is it possible to run Apache and PHP on a server but to limit PHP to one part similar to setting a document_root for PHP? I do not want the PHP files to work on the static part.

Lastly, does anyone know of any "best practices" when it comes to setting up development / test environments? I am looking for any helpful information I can get.

Thanks

Webmonkey

You can probably enable/disable PHP in Apache virtual hosts.

Look at http://www.linuxquestions.org/questions/linux-networking-3/turn-off-disable-php-for-some-virtual-hosts-in-apache-412577/

amen

Lastly, does anyone know of any "best practices" when it comes to setting up development / test environments? I am looking for any helpful information I can get

Best practice would be to (brief overview. Can expand to more detail if required)
1: Have a development environment for each developer on their pc taking to a shared database (if you use one). All developers use some source code repository. All developers compile and unit test code on checkin.

2: You have a build server which only contains the software required to do your builds. You build the software here and deploy to your test environment. Pref use a build manager tool.

3: Test environment replicates the Live installation in terms of software on the server, application setup, server security etc. You don't need to same spec hardware but if it is different make sure it is of lower spec. All testing by the QA/Test team should be on this server. All bugs/issues should be fixed and released via the Build server. Developers should not be installing fixes/patches outside of the release cycle. No development tools on the Test server. Once QA passes the release its off to the customer test server.
Automated regression testing should occur at this stage.

4: Your customers should really have a test environment where they can test and sign off. Once the customer signs off then the release moves to Production

5: Production Server. Release gets here after testing is completed.

Hope this helps.

croo

If you have 1 test system but want to replicate two (or more) production servers why not run multiple VMs on the test system? Then you can deploy to the test VM in exactly the same configuration as the production machines. Actually they could and should, initially anyway, be exact copies of production machines in terms of OS, database, apache, php etc versions. I say initially because, besides your own code, you might want to test new versions of the middleware (php, db etc) being used before deployment to production too!

amen

I say initially because, besides your own code, you might want to test new versions of the middleware (php, db etc) being used before deployment to production too!

but if you are testing new version of php, db etc they should be tested a new test server that is not used to testing production releases.

Once tested and verified on the new test server (load/stress testing, application testing etc) then it should move to the production test server.