Hi there

Interesting article, but lacks what the DBA's really need, that being change control templates , specific (point form) steps used in example environments and example security settings to control developers.

I am very strict with change control at all levels, no matter the garbage you hear about "extreme programming", there is no place for slackness in development. Even so, there are levels of control to suite the particular environment as not everyone is running a train control system.

Here is what I do:

Development:

+ all db schema changes are made by dba only

+ db changes are documented and analysed by dba through change control form

+ db access via roles at all times, dba manages and communicates the security paradigm clearly and checks regularly during dev cycle. Nothing goings to test or prod without following the rules.

+ developers do get ddladmin and db_security db privs for managing their views and stored procs. All objs must, at the end of the day, be owned by DBO.

+ server admin access open

+ installation of SW on any box is documented via DBA

Test:

+ change control form clearly documents schema changes

+ db backed up

+ changes applied, views/stored procs etc applied

+ app and db security privs are "what prod is like" to ensure proper testing occurs

+ server access is locked out to select few (senior analysts etc that manage integration and system testing cycles)

Prod:

DBA only.

Strict dev -> test -> pre-prod (compile server, mirror of prod) before anh change is applied.

All replace components are backed up before the change.

There is a hope range of issues etc to cover, but just some thoughts to start with.

Cheers

Chris K

http://www.chriskempster.com