Development vs Production Server Rights: DBA vs Developer

  • Hi,

    I'm curious as to how other companies are managing their servers (production and development) and how the roles of DBA and Developer are defined within each these database environments. Additionally, if the environments are "locked down" to developers on the production server, how are you implementing change management/requests for maintenace issues ie: schema changes; restores ... 

    Any thoughts, experiences, docs or templates that I could review would be greatly appreciated.  Thanks. Jeff 

    Many thanks. Jeff

  • This was removed by the editor as SPAM

  • We have a four person data management group that does all the traditional dba jobs of installation, upgrading, backup & recovery, security, performance tuning, and user administration.  Additionally, they help developers with logical and physical data modelling.  The group creates databases and tables in development and is responsible for all object creation and data migration in production. 

    Developers have read access to nearly all databases in development and production.  They can create stored procedures in development, but cannot create any database objects in production.  Nor can they create production jobs or DTS packages.

    Production table schema and stored procedure changes are requested by  developers via email request and implemented by the data management group.

    This scheme works well in our environment with about 40 developers and 4 DBAs.

    Greg

     

     

    Greg

  • I manage 10 DBAs in a multi-platform, enterprise shop that supports a 12,000 person company. Here the production DBAs have access to production and development. Development DBAs have access to development only. Even the app support folks do not have access to production, but we do provide a 2nd environment called mirror that is refreshed from production every night, some data scrambled, some security changed.

    To promote changes, a request is submitted, reviewed by DBAs and others and approved and then the production people move it in.

     

  • We have 3+ developers and myself. I'm the DBA but I do some development here and there.

    We are in the process of switching over our way of working. We will have a test environment. Developers will have access to do whatever they like to Test. When they are done, I will put it into "user acceptance testing" which will be on the same server so the users can test the apps, objects, whatever. The developers will be allowed to tweak these objects as the testing proceeds. Then, when testing is complete I will move the objects/whatever into production. They will not have any access to produciton other than to read most objects. I will periodically refresh the test area with the production structure. 

    We like this model b/c they won't bog me down with small db changes (they are quite skilled) and I get to do a "test implementation" prior to a production implementation.

    This is not exactly ideal but I think it will work quite well, there is only one of me and limited $$ for hardware/licenses.

    Chris.

    Chris.

  • I am a SQL Server Developer and I have access to development only but not SA permission.  I cannot create or look at jobs.

    I can look at tables at production but I can't look at DTS packages and jobs in production.

    When production job went down, DBA gets call and then he calls me for help, how am I going to help him if I can't see anything?

    I just want to know once the job goes to production, what is the role of the developer if the job goes wrong in production ?

    Anyone has this confusion!

    Thanks

     

     

     

  • We're working through this where I work as well. Right now for the most part developers have a local copy of SQL (dev edition) and do all their work there. Then we migrate to production. It's corporate work and typically are not huge changes. We're probably going to move to having a QA server as a middle step to be sure we get all the changes moved correctly. Right now the only time we need a real dev server is if we have a db large enough that we can't copy it local (rare in my environment) or we need bigger hardware. I like letting them make their own changes - builds skills and minimizes bottlenecks.

  • Hello there,

    I did not want to start a new thread, and came across this one.

    I wonder how you arrange the security regarding logins / users. If a developer needs to test and s/he needs a new login/user for that, do you give her/him the permissions to do add a new login/user?

    regards,

    Hans

  • Hello,

    Nothing is static - all requests are evaluated on a case by case for the business driver. Having said this, here is our environment's general guidelines:

    Production DB Servers: are locked down as best as we can (only READ/WRITE for app functionality); DBA runs scripts after developers have tested

    Developemnt DB Servers: developers have all rights (mssql db roles) except db_owner and db_accessadmin; responsibility to create/add server/db users and perform backups/restores lies w/DBA. Developers have full DDL/DML.

    It's not perfect, but it works for us.

     

    Many thanks. Jeff

  • Thank you for the reply Jeff.

    Coming from a developer background I can imagine that our developers would want to be able to add users themselves to the databases on the development server, in case they want to test something on short notice.

    The developers would only get read permissions on the production server.

    I guess it will always be dependent on the situation; for the moment we will choose for a hybrid solution with the resposibility for security shared between the dba and the developers. Also not ideal.

    Hans

Viewing 10 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply