We are not a US based company but approach is similar. Real
development environment is out of our scope - we don't maintain it. We
maintain test cycle databases (normally 3 DBs for acceptance by
different groups), several pre-production DBs (normally 3-4 DBs again
for other groups), one production and one production look-alike (kind
of post-production). Depending on functional requirements they are
refreshed from prodution backup, functional refresh, or production
based TTS.
Changes are coming with new software versions and going through our
record tracking system.
--
Best regards,
Alex Gorbachev
On Sun, 12 Dec 2004 11:18:32 -0600, DENNIS WILLIAMS
<DWILLIAMS_at_lifetouch.com> wrote:
> Agree totally with the use of scripts to make database changes.
> One idea is to base your development on a 3-database model. Production,
> staging, and test (or development). Update the test and staging as required
> by cloning production. This way you are guaranteed to have an exact copy of
> production.
> Ideally you clone by recovering a backup. That way you frequently test
> your backups.
> Staging acts as a buffer between test and production. Often you can't
> refresh the test database because of various developer activities in
> progress, so staging is where you test the changes before they hit
> production.
> This method is from ITIL. The only way to combat a massive force like SOX
> is to pit it against another massive institution.
>
> Dennis Williams
> DBA
> Lifetouch, Inc.
--
http://www.freelists.org/webpage/oracle-l
Received on Sun Dec 12 2004 - 13:31:59 CST
