Fog Creek Software
Discussion Board

Dev, Test, Production - does this make sense?

I've been thinking about "how things work" and how I would set up a proper development shop. Here's what I'm thinking...

Development - sandbox. There are dev servers that approximate production. Developers run their own machines. One or two additional "beta/proof of concept" servers if appropriate.
Unit testing for client apps is done in VMWare.

Test - developers can only access the test environment as normal users (so they can see/replicate errors). QA "owns" the test environment. Production applications and databases are mirrored down to test on demand (and frequently). Applications to be tested are only scripted in with the production deployment scripts.

Production - only the sysadmin has sysadmin rights on Production. Applications are only scripted in with deployment scripts.

Firewalls between each layer to prevent crosstalk (most notably to prevent a test app from using a hardwired connection to a dev database and nobody noticing)

Development "tools" (fogbugz, Rational, etc) are deployed based on what kind of access is needed - if it's truly a dev-only tool, it goes in Dev. If it's testing related, it goes in test. If customers will see it (like Fogbugz in feedback mode) then it goes in production.

Is that about normal?


Thursday, April 10, 2003

We usually expand on that a bit further: DEV, TST, UAT, PRD -- where DEV, TST and PRD are pretty much as outlined in your post. UAT is "User Acceptance Test". TST is limited to *internal* testing and QA. UAT is where the *client* (user) gets to play around and see if the system passes their acceptance tests.

To answer your question, yes -- your setup is pretty much "normal" for most shops.

Sergent Sausage
Thursday, April 10, 2003

Add in a DMZ for all the critical junk that everyone needs to get to, the housekeeping.

Simon Lucy
Thursday, April 10, 2003

The best experience I ever had the company did it similar to how Sergent Saus described.

Development (Sandbox)
Staging (User Acceptance Test Also Here)

It was awesome!!!!!!

Now the current company I am with uses:

Test - unreliable env so devs are forced to use QA most of the time (bad bad practice)
QA (devs, testers & User Acceptance here = many problems)

Thursday, April 10, 2003

What you describe is a pretty standard setup.  One place I worked also had a "demo" environment, which basically was a stable environment for brand new code and products which hadn't been QAed properly yet but still needed to be demonstrated to prospective customers in order to motivate sales. 

Colin Evans
Thursday, April 10, 2003

In addition to a Dev, QA, Stage, Prod and Demo environment we have a Training environment.

Demo and Training mimic production but don't work on live data.

Stage is used to test our migration from QA to production.  This gives us confidance that the production rollout won't break stuff.

At one point we had 2 dev and  2 qa environments.  One was a "fast track" and the other was a "slow track". It was a mess to keep them in sync and we've done away with it for now...

Thursday, April 10, 2003

There's no single answer. It needs to be tailored to the type of software being developed. As others have pointed out, DEMO and TRAINING environments can make sense. For my current project, it wouldn't.

I work on a large-scale EAI project for a major telco. We have Development, System Intgeration Testing, Stress and Volume Testing, Production Support, and Production environments. (Production Support is for replicating Production problems.) Our app is distributed across 10 different machines. There are 78 machines across these environments for fourteen separate apps.

We actually have 3 separate SITs that run as separate instances on the same machines. Right now, I'm trying to coordinate testing of a new release of our app and a regression test of a new release of one of our major interfacing systems a month later (one of six interfaces). So we've got the current version of code in Production and Production Support, we've got the new code in SIT1 and SIT2, each pointing to completely separate interfacing system's SIT environments. Not as easy as it sounds - the SIT environment for the interface we're regression testing runs upwards of $7 million in hardware. Oh yeah, we have two development groups - one doing major enhancements and one doing bug-fixes.

Needless, to say "Build in one-step" is a crucial capability. We're not there yet but we're getting there.

Jim S.
Thursday, April 10, 2003

*  Recent Topics

*  Fog Creek Home