April 28, 2004

Going through the cycles

Ben Forta recently surveyed developers on his site for where they do development. The results were a bit disconcerting.

14% do development on a production server.
52% use a dedicated development server.
32% use the free Developer Edition.

As web technologies become more prevelant in an organization's business operations, imho there needs to be 4 dedicated systems.

First, a production system with the goal of 99.9% uptime. The cost of bring down a production server, is that the business can't work. So to totally eliminate all risk, no development or testing should be done on a production box when it is in production.

Second, a disaster recovery system should be available. This should be an exact replica of production, in another physical location (preferrably out of the building). There needs to be measures in place to ensure synchronization between the production and disaster recovery.

Third, a quality assurance or testing system should be available. This should be another copy of production but with controlled and released changes. In the ideal world, this test system would undergo daily automated test cases. There would be stress testing, interoperability testing, and integrated testing. The outcomes of this testing would ensure that what ever changes scheduled to be released would not affect the business with undesired results.

Finally, a development system with source control. A source control tool, allows for changes to be tracked, eliminates the possiblity of developers overwriting code changes. A development system on a server also allows for nightly backups in case a local pc crashes.

The movement through the stages, from development to test to production and disaster recovery, ideally would be done by a change control of configuration management process. The goal is to minimize impact to the business operations.

Is this an expensive solution, for you I don't know. What is the total cost of operations when your server is down? What is the cost of losing certain data elements? I guess it comes down to how much risk your organization can withstand.

Posted by Elyse at April 28, 2004 6:35 AM | TrackBack
Comments

Excellent point. This is certainly the ideal setup/process and I agree that the results were somewhat disappointing, but there also wasn't anyway to choose the setup you have described - in the survey, it was simply "which of these do you use"? So I'm not sure exactly what this survey can even show, other than some folks use production servers to develop on! Yikes...

Posted by: Scott Keene at April 28, 2004 9:55 AM

Here's what we have:

1. Developer Edition and copy of site on (almost) every engineer's desktop / laptop (connected to shared dev db or local copy if they want).

2. Shared dev servers (different code branch on each) connected to shared dev db (or branch variant). Allows shared unit testing and pre-QA integration testing. Three web/app servers plus db server.

3. Shared QA servers (different code branch on each) connected to shared QA db / branch - for QA team testing. Three web/app servers plus db server.

4. Integration environment - small mirror of production connected to integration db. Used for (a) pre-release testing of code and db changes (b) load testing. Two web servers, two app servers, db server.

5. Production environment with full failover. Ten web servers, four app servers, db server plus backup db server.

Our apps connect to a JMS message hub on the backend and we have a shared dev instance, a shared QA instance and a production cluster - just three layers and only production lives on its own servers (dev and QA share with an existing dev / QA server).

Posted by: Sean Corfield at April 28, 2004 5:29 PM
Post a comment









Remember personal info?