By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,137 Members | 2,282 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,137 IT Pros & Developers. It's quick & easy.

Database Environment Naming Production -vs- Development

P: n/a
I have been looking for some documentation that would support or reject
my opinion on Production -vs- Development naming conventions. I
believe that each environment should be housed on separate servers with
identical names, access, users, stored procs....... If you either
agree or disagree with this methodology, I would appreciate your input.

TIA,
Bill

Jul 23 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
With the same access? In most situations I don't want developers to
have the same access to production as they have in development. I
pretty much never want my users to have access to development either.

Other than that, I would agree. I think that every item that you have
to change between development and production is one more item that may
get you when moving changes from development to production.

In my environments I usually have a QA or testing server as well. This
one will more closely mirror production so that moving changes from QA
to production involves no manual changes at all - everything is
automated. This helps to ensure that no unforeseen bugs get moved into
production as the result of an errant upgrade script. The upgrade
scripts are run on QA, which is identical to production at the start
(often synchronized by a backup/restore unless the data is sensitive or
too large for the QA server). If the upgrade scripts work successfully
on QA and testing the changes is successful then confidence is pretty
high that they will work correctly in production.

HTH,
-Tom.

Jul 23 '05 #2

P: n/a
I agree with Thomas. You cannot / should not test on a Dev server. So
you need at least three environments as near identical as possible.
Developers don't get access to Production except to troubleshoot a
problem that you can't repro elsewhere (unfortunately that happens).

--
David Portas
SQL Server MVP
--

Jul 23 '05 #3

P: n/a
Thank you all for your responses.
And the access does change for Developers, we grant SELECT access to
view potential data issues and we also have Production control to move
both Databases and Interface methods (Executables and Web) from
Development to Production. There has been a desire to create a three
tier type environment, as we cycle out Production equipment I am keeping
it for the Development environments, so in another year or so I should
have the equipment for the 'QA' level.

Thanks again,
Bill

*** Sent via Developersdex http://www.developersdex.com ***
Jul 23 '05 #4

P: n/a
Bill Willyerd (bw*******@dshs.wa.gov) writes:
I have been looking for some documentation that would support or reject
my opinion on Production -vs- Development naming conventions. I
believe that each environment should be housed on separate servers with
identical names, access, users, stored procs....... If you either
agree or disagree with this methodology, I would appreciate your input.


If we were do that in our shop, we would have to have a load of servers!

More generally, it depends on what your situation is. The above could
be a good idea for in-house applications, where there is exactly one
production server. (We develop a product, and we have one development
environment and one test environment for each customer and for each
version in production, test and development. That's a lot of databases.)

I would say that the key point is that you have separate servers.
Testing on a second database on the production machine can lead
unpleasant incidents, because test reveals a query with a poor query
plan.

Wether the database should have the same name? Of course, it helps,
but what if you need more than one testing environment? One of our
customers at one point had 3-4 test databases, all for our application.
I can reveal that they did not have four test servers. Thus, it is a
good idea to make it easy to switch database in the application.

As for the same stored procedures etc, this is best achieved by having
a version-control system as the definition of your system.
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
Jul 23 '05 #5

P: n/a
Hi

If your servers have identical names then they can not be on the same
network!!

John

"Bill Willyerd" <bw*******@dshs.wa.gov> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
I have been looking for some documentation that would support or reject
my opinion on Production -vs- Development naming conventions. I
believe that each environment should be housed on separate servers with
identical names, access, users, stored procs....... If you either
agree or disagree with this methodology, I would appreciate your input.

TIA,
Bill

Jul 23 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.