Do you have a local test environment?

[Sparks]

Okay WD, so you're talking about developing on the live server, but in a test directory. So a remote test environment then. Which is a lot safer than what I thought you were saying (and which I've seen done commercially, without version control...).

What do you do then, if you make a mistake and the remote test environment crunches on the live database instead of a test database? (This can be prevented on a local test environment more easily than on a remote one). And what if you want to test the site on a new version of some part of your LAMP stack? And how do you guard against disaster in the server farm itself (a major fire, for example)?

 

[webdream]

hi sparks,

We would also produce a DB clone for development purposes.

Fire in the Data Center? ... have a look at deg.ie , they probally have all the info there on fire suppression etc.

To be honest, the only real risk of using a live server as a test environment would be through sloppy or experimental coding. This could increase server load if you had multiple sql queries running in an eldless loop for instance. If there was any significant risk of our dev. work affecting live websites, we would indeed use a local machine.

Let's be realistic here, your clients web apps. are exposed to a greater risk from other sources.... being on a shared box for instance where you don't know who is doing what with other sites, or using a box where open source apps. are running (Joomla etc.). In terms of a discussion about risk reduction, these factors are of a far greater consequence.

 

[mneylon]

And how do you guard against disaster in the server farm itself (a major fire, for example)?

If you use a proper data centre, as opposed to a comms room in an office building, then fire isn't an issue.

 

[webdream]

good point... wish someone would point that out to all these companies that buy local mail servers

 

[Sparks]

hi sparks,
We would also produce a DB clone for development purposes.

Yes. The problem lies in that one time that you copy off the live site to a development directory, forget to change the configuration.php file (or its equivalent), and mangle the live database as a result.
With a local test environment, you can't do that (assuming your remote site database is setup in a sane way to only allow localhost access).

Fire in the Data Center? ... have a look at deg.ie , they probally have all the info there on fire suppression etc.

Fire was the first thing I thought of, but there are many others that the data centre company can't prevent. Granted, we get few earthquakes here, but we do get terrorist attacks (or used to at least, but I'm a pessimist ), muppets with JCBs digging up cables, etc, etc, etc. And while the hosting company will try to prevent this sort of thing, you're still the one that suffers if they slip up. At least with local environments, you have your copy of the site in subversion, so you can get back up and running with somone else a bit faster.

To be honest, the only real risk of using a live server as a test environment would be through sloppy or experimental coding. This could increase server load if you had multiple sql queries running in an eldless loop for instance. If there was any significant risk of our dev. work affecting live websites, we would indeed use a local machine.

And if there was any significant risk of me being in a car accident, I'd put on my seat belt just before the crash.

Let's be realistic here, your clients web apps. are exposed to a greater risk from other sources.... being on a shared box for instance where you don't know who is doing what with other sites, or using a box where open source apps. are running (Joomla etc.). In terms of a discussion about risk reduction, these factors are of a far greater consequence.

First off, we're not talking about a shared box, but colocation. Or at least I was. Shared boxes, we agree on this, are a bit more risk than I'd like for something critical.

Secondly, I'll trust something that's open source like Joomla or PHP or Apache or Postgres or Linux (heck, even MySQL) long before I'll trust something closed source where I can't figure out what the heck just went wrong. And in terms of risk reduction, I'd put development on the live server by a new employee who's not yet up to speed and on whose job-specific training your uptime is depending as being about the biggest risk going.

 

[Ciarán Mc Cann]

I sure do!! I couldnt live with out it, I use WAMP 5 , its very very useful. I develop all my PHP websites on it and also PHP and Mysql applications I develop also. Best piece of software I have ever downloaded!!

 

[ConorP]

VMWare is a wonderful thing.

 

[squibs]

I tend to develop on the server also. Most of my sites are for first timers, so I hide the real thing behind a holding page, and make it live once the client has signed off on it. I do versioning locally with copious use of copy/paste/rename locally. Not textbook I know, but it works for me.

I had too many disparities between the XAMPP environment and live servers - some down to windows/linux stuff and more down to the vagaries of hosting environments - php.ini and stuff. I couldn't justify dedicating a box to a linux install, and dual boot takes too much time to - well... reboot.

VMware does look like a a good solution, if you factor in that you will still have hosting environment differences. I installed a fedora image with the player version but never spent much time on it. Does it burn any resources when the player isn't running? Can windows browsers access sites served from apache within the player? If so what about browsers on another machine on the network?