DTS package - standards?

  •     Sometimes we get DTS packages from developers that have to go into prooduction right away. We (DBA's) never got to look at them before hand, never even knew they were being put together until we're told to put them in production. Once they are in production they pretty much become our problem. Some DTS packages are uncomplicated and not a big deal but some can be very difficult to try and figure out.

       We're thinking of setting up standards for packages. Does anyone have standards for DTS packages in their shop that they would like to share?

       Also, as this is the only shop I've worked in as DBA, I was wondering if it's the norm in other shops to keep DBA's out of the loop until just before something needs to go into production?

     

     

     

  • Guess it would depend on what you define 'developers' as.

    I work in a DEV dept. that is both C# and SQL people, some both.

    So the SQL guys do the DTS stuff. It goes through local testing on their machine (where possible) then goes through the DEV server, and to two additional environments before going to PROD.

    We are required to give the PROD DBA's release notes or instructions on how to setup and run stuff, but besides that, they rarely have problems, and do only a small amount of troubleshooting.

    Anything that doesn't work is pushed back for us to fix.

    Personally if I was in a one DBA shop, I would require review of all stuff hitting the DB before it goes to PROD.

    Do you have a dev environment? Are the developers testing their DTS packs on dev servers?

  • OK - I guess my shop might be the exception and not the rule then.

    It sounds like the developement cycle at your place is stricter. For the most part the developers have a test server not the additional environments you mention.

     

Viewing 3 posts - 1 through 2 (of 2 total)

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