Build an automated script or batch file to rebuild your test region from
production on a regular basis.

Build another automated script to promote your projects from test to
production systems. When we promote from test to production, our end
users are generally not aware of the change unless they refresh their
screen across the actual promote time frame.

Make extensive use of automated testing tools (jUnit, dUnit, vbUnit,
cUnit, etc). Don't promote to production without 100% pass on all
tests. Build this into your automated promote from test to production.

Our shop does this quarterly. It takes us about 2 days to completely
replicate our production environment without shutting down. The order
in which we snapshot tables to migrate them from production to test is
important, since the data is live at all times.

NEVER test in production. It costs my company hundreds of dollars per
second if something goes wrong in production. Some of our vendors have
gotten really upset with us because we know when their processes break
(and hold up our processes) and we call if they are not corrected in 10
minutes.

On Fri, 2005-03-25 at 14:28 -0800, Rich Pinder wrote:
>
> I've currently got a 'test' database for developement (on the local
> machine), plus the 'live' database which is out there in the world (and
> soon, it will indeed be LIVE!).
>
> I will be both adding new tables, plus (undoubtebly) be modifying
> existing ones. Also, after creating new tables, I'll surely be
> populating them - and sometimes that seems to be a long, iterative
> process (import, check, drop, recreate, import again).
>
> And I'm worried about snafu's occuring - trying to replicate things
> perfectly.. but missing important steps along the way.
>
> Just wanted to know how others minimize problems. Maybe the whole
> notion of keeping the 'test' database is not a good one ? Maybe I shoud
> ONLY use the DDL up on the 'live' database - then after its working,
> just GBAK the 'live' one up, and restore it on my test machine (where I
> only use it to test DML from my application)??
>
> Thanks in advance for your thoughts.
>
> [if you do all design work up front, and never peform modifications as
> the project develops, please disregard the post !]
>
>
> Rich Pinder
> USC School of Medicine
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>