Re: Splitting production and development/test at the DBA level?

They were/are going to do that at the last place I worked. I'm in two minds
about it.

In it's favour dedicating DBA resource to development does improve the
quality of both code and design. I like that a lot. I also like the idea
that those responsible for development are also responsible for the release
package being of sufficient quality and standard that someone who hasn't
previously run it can do so successfully. I also am totally behind the idea
that you don't let development into production (fighting that battle here,
relatively easy with in-house staff, impossible maybe with 3rd parties).

I don't like the idea of having a team of just 2 (my last place had 4
permanent DBAs and part of the 'reason' for the split was that both
production and development needed 3 dbas but didn't recognise it yet). A
split of 2/6 suggests to me that the perception is that a 3rd of the
workload is in test and development put together and 2/3 in production. It
would be interesting to see if that reflects reality,  I'd almost expect it
to be the other way around but a review of support tickets/work records
would show that assumptions truth or otherwise.

As far as not knowing what is coming, if the current culture is that
development don't talk to production about a release schedule you've got
bigger issues than who does what.

On the whole I don't think it a bad idea provided that the team is big
enough in both areas and that dbas still get to work on what suits them
(might mean mixing and matching the teams from time to time) so that you
maintain the interest and career development of the guys.

On 12/12/06, Michael Kline <mkline1@xxxxxxxxxxx> wrote:

 I've got a client that is considering splitting devl/test and production
at the DBA level.



There are only about 8 Oracle folks, and that would put 6 on Production
and 2 on test and there are about 70-80 databases.



This all has something to do with a Gartner paper that was some 7-8 years
old.



Has anyone tried this before and what were the results?



Migrating new code forward just sounds like it will be horrible because
now TWO DBA's will be involve and probably be almost totally unaware of
what's coming and the like.



The strange thing is, this client is into "pools" big time where you get a
DBA from the pool to work on what ever. That is pretty much how they were
doing it now. Yet, being "in line" with this pools thing, they now want to
make two pools and then make it so prod would have no access to devl/test
and devl/test will have no access to prod. It reminds me of like WalMart
type stores. "Sorry, that's not my department." It's got the DBA department
quite concerned.



The paper was supposed to say this was the thing to do, and perhaps would
make SOX happy.



Michael Kline

13308 Thornridge Ct

Midlothian, VA  23112

O: 804.744.1545

Fax: 804.763.0114






--
Niall Litchfield
Oracle DBA
http://www.orawin.info

Other related posts: