Development - Test Environment Questions

Hi,
I've been given the task of creating a dev/test environment. Currently we
have several production applications using databases on a common SQL Server.
If changes are required, the developers are performing the changes on the
production system - yea I know BAD,BAD,BAD - but I didn't set this up but
instead inherited it. I'd like to configure a dev/test environment to move
the devs off of the production system and to faciliate their development of
future projects coming up soon.
How is your dev/test environment configured? I'm looking for a few examples
here that I can work with to implement our dev/test based on our budget and
system capabilities.
I.e., Each dev has their own sandbox or each dev shares a common dev env -
then changes are implemented to test env (and by who - dev or dba - and
how - scripts) etc... then scripted to deploy on prod systems etc... also
we image/ghost systems or use VMs and also we use Visual SourceSafe to...
Trying to come up with a solid game plan here.
Thanks for any input.
Jerry
Jerry Spivey wrote:
> Hi,
> I've been given the task of creating a dev/test environment. Currently
> we have several production applications using databases on
> a common SQL Server. If changes are required, the developers are
> performing the changes on the production system - yea I know
> BAD,BAD,BAD - but I didn't set this up but instead inherited it. I'd
> like to configure a dev/test environment to move the devs off of the
> production system and to faciliate their development of future
> projects coming up soon.
> How is your dev/test environment configured? I'm looking for a few
> examples here that I can work with to implement our dev/test based on
> our budget and system capabilities.
> I.e., Each dev has their own sandbox or each dev shares a common dev
> env - then changes are implemented to test env (and by who - dev or
> dba - and how - scripts) etc... then scripted to deploy on prod
> systems etc... also we image/ghost systems or use VMs and also we use
> Visual
> SourceSafe to...
> Trying to come up with a solid game plan here.
> Thanks for any input.
> Jerry
At most companies where I've worked in the past, we had development
servers that were used strictly for development. They generally
contained stripped down data from the production databases with any
customer sensitive data masked. Lead developers generally had dbo rights
and may even have admin rights depending on the size of the company.
Version control software was used for all object changes. Initial
application testing was done on the dev servers.
QA/Test servers were not managed by development. They were usually owned
by QA group. We would provide detailed scripts to update QA servers with
the necessary changes. Users would test the applications on QA servers.
QA servers have data that more closely mimics production in terms of
data value distribution and quantity and may even be created from
production backups. Sensitive data was not masked back then, as I
recall, but it may have to be today. QA has the ability to reload the
database in case the migration to QA fails. It's important to be able to
always start from an exact copy of the production database schema.
These days, you can use multiple SQL Server Instances to save hardware
(assuming you have the necessary memory). VMs, while convenient, are
probably not ideal for performance testing. But I'm not well informed
about the capabilites of the server VM products.
If everything tested ok, the updates were escalated to production.
David Gugick
Quest Software
www.imceda.com
www.quest.com
|||Thanks David.
Looking into using named instances with EE to help control costs. Will be
looking into implementing Visual SourceSafe as well.
I noticed you work for Quest. I have a few questions about the Quest
Central if you're open to them. Please email me if so.
Thanks
Jerry
"David Gugick" <david.gugick-nospam@.quest.com> wrote in message
news:%23YygmKIaFHA.1044@.TK2MSFTNGP10.phx.gbl...
> Jerry Spivey wrote:
> At most companies where I've worked in the past, we had development
> servers that were used strictly for development. They generally contained
> stripped down data from the production databases with any customer
> sensitive data masked. Lead developers generally had dbo rights and may
> even have admin rights depending on the size of the company. Version
> control software was used for all object changes. Initial application
> testing was done on the dev servers.
> QA/Test servers were not managed by development. They were usually owned
> by QA group. We would provide detailed scripts to update QA servers with
> the necessary changes. Users would test the applications on QA servers. QA
> servers have data that more closely mimics production in terms of data
> value distribution and quantity and may even be created from production
> backups. Sensitive data was not masked back then, as I recall, but it may
> have to be today. QA has the ability to reload the database in case the
> migration to QA fails. It's important to be able to always start from an
> exact copy of the production database schema.
> These days, you can use multiple SQL Server Instances to save hardware
> (assuming you have the necessary memory). VMs, while convenient, are
> probably not ideal for performance testing. But I'm not well informed
> about the capabilites of the server VM products.
> If everything tested ok, the updates were escalated to production.
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
|||Jerry Spivey wrote:
> Thanks David.
> Looking into using named instances with EE to help control costs. Will
> be looking into implementing Visual SourceSafe as well.
> I noticed you work for Quest. I have a few questions about the Quest
> Central if you're open to them. Please email me if so.
> Thanks
> Jerry
>
The best way for you to get information and help with the Quest product
line is to contact sales. Our offices and numbers are located here:
http://www.quest.com/company/us_offices.asp
David Gugick
Quest Software
www.imceda.com
www.quest.com
|||Change management is the term.
http://www.innovartis.co.uk/pdf/Inno...ange_Mgt. pdf
This is a white paper on the subject using Source Control (Visual Source
Safe) as the back bone of the approach. The application DB Ghost
(www.dbghost.com) was built using this methodology.
regards,
Mark Baekdal
http://www.dbghost.com
http://www.innovartis.co.uk
+44 (0)208 241 1762
Build, Comparison and Synchronization from Source Control = Database change
management for SQL Server
"Jerry Spivey" wrote:

> Hi,
> I've been given the task of creating a dev/test environment. Currently we
> have several production applications using databases on a common SQL Server.
> If changes are required, the developers are performing the changes on the
> production system - yea I know BAD,BAD,BAD - but I didn't set this up but
> instead inherited it. I'd like to configure a dev/test environment to move
> the devs off of the production system and to faciliate their development of
> future projects coming up soon.
>
> How is your dev/test environment configured? I'm looking for a few examples
> here that I can work with to implement our dev/test based on our budget and
> system capabilities.
> I.e., Each dev has their own sandbox or each dev shares a common dev env -
> then changes are implemented to test env (and by who - dev or dba - and
> how - scripts) etc... then scripted to deploy on prod systems etc... also
> we image/ghost systems or use VMs and also we use Visual SourceSafe to...
> Trying to come up with a solid game plan here.
> Thanks for any input.
> Jerry
>
>