Post reply

deployment documentation

  • February 21, 2008 at 3:59 pm

    #74047

    Does anyone have some standard forms for deployment of SQL DBs, DTS, Etc.

    We need to better document user requests comming into the system and a good form would be a first step. Second step will be to put the forms online so they can fill out from the web...

    Thanks in advance

    Eric Peterson

  • February 21, 2008 at 4:11 pm

    #780899

    I don't have a great one, but usually I've asked for dbname (if it matters), size, expected growth (prefer percentages here), downtime/data loss allowed (minutes preferred), users (count) and security method (Windows Auth, SQL Auth).

    You can ask for much more, but I've found most of the time it's users or developers that need to deploy something, they don't know all of this stuff, and most importantly, they don't care. They need it deployed and don't want to think about it.

    I'd ask for basics, preferably in a form, and be sure you allow for pad in case they've grossly underestimated.

    (helps to track things after the request over time as well)

    Follow me on Twitter: http://www.twitter.com/way0utwest
    Forum Etiquette: How to post data/code on a forum to get the best help
    My Blog: www.voiceofthedba.com

  • February 21, 2008 at 7:10 pm

    #780934

    Eric Peterson (2/21/2008)

    Does anyone have some standard forms for deployment of SQL DBs, DTS, Etc.

    We need to better document user requests comming into the system and a good form would be a first step. Second step will be to put the forms online so they can fill out from the web...

    Thanks in advance

    Eric Peterson

    No... you need a good "Ticket" tracking system. Every "problem", request, enhancement, inhouse repair, etc, etc, etc, should and must have a Ticket number (complete ticket history should be provided in each proc, UDF, view, table creation/modification script, etc). The Ticket tracking system should have the obvious things in it including what the problem description was, the fix, the customer, objects affected, who worked on what, and the number of hours it took, etc, etc, etc.

    It's the only way to keep track of what you're doing and the only way to "get smarter" about how long fixes take. It will also help you keep track of the real costs of repairs.

    Save yourself huge headaches down the line... no code should move to production without a Ticket review/signoff and the Ticket rev history should also be briefly included in the header of all code.

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".
    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • February 21, 2008 at 7:12 pm

    #780935

    One more thing... the ticketing system should have the concept of "Parent Tickets" and "Projects" associated with it. Seriously, this is the only way to keep a handle on who's doing what to which code for how many customers and what it costs.

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".
    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • February 21, 2008 at 8:25 pm

    #780940

    Jeff Moden (2/21/2008)

    One more thing... the ticketing system should have the concept of "Parent Tickets" and "Projects" associated with it. Seriously, this is the only way to keep a handle on who's doing what to which code for how many customers and what it costs.

    And...don't forget the "ticket enforcement system" (cheapest part of the whole process). It's about 3' long, usually made out of solid ash wood. Perhaps with the word Rawlings etched into it....:D

    All kidding aside though: getting a ticketing system together is phenomenal, but a. it's a lot of work to get people to do it, and b. requires strict enforcement. Meaning - someone is going to need to ENFORCE it. So - no, don't break their hands physically - but there can be no backsliding, and for a while no tolerance of "not following the new process" or the whole system falls apart. NO changes outside of the new process. And that includes...you.

    I tried to put one in play, and ultimately failed. I didn't get cooperation from above, and didn't get the time left in the day to make sure personally run around and hunt down the slackers.

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • February 21, 2008 at 8:49 pm

    #780945

    It was easy for us... we had a great junk yard dog for a DBA who said "Sure... I can keep anything out that doesn't have a signed off ticket". And he did!

    Quality of code went way up, defects came way down. Approached the Nirvana of "Zero Defects". Change controls (outages to put code in) went from 3 hours down to about 15 minutes.

    Like Matt said, you gotta have initial buy in and enforcement. It must be a team effort or the team will fail. It should not be developers against the DBA... everyone must buy into it... everyone will benefit.

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".
    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • February 22, 2008 at 12:14 pm

    #781207

    Yes, we do have a home grown case management system.

    The problem is that it is a text field......and the developers can type anything and always leave out things like SQL Server, Database, securtiy access, expected # of rows in result, etc.

    What I want to implement is the form as part of the ticket management system.

    If we do it really well.....I can take the text directly from the ticket, push an execute button and it will return the result set ( ex: 22 row(s)... ) which will be stored in the resolution of the case.

    With that said, I am looking for a form(s) to base the DBA task request upon.

    Maybe seperate ones for: Jobs, DTS, Backups/Restores, DDL, DML, DB Level requests or New DBs, SQL Server installs, Security. Can anyone think of any others?

    Thanks again

    EP

    P.S> I do like the speak softly and carry a big stick approach.....lol

  • February 28, 2008 at 1:01 am

    #783021

    Hi,

    Just to add to the discussion 🙂

    We have a strict change control system and the change MUST go through test and be tested before it gets near to going to production and I fully agree with previous comments...wish I had a big stick 🙂

    I am responsible for the production environment so I certainly do not want dodgy developer code bringing down the system.

    I do have concerns however, and I not sure anyone else feels the same. Production systems are now getting pretty complex and to fully test a change with confidence, the test environment must mirror the live environment...is that fair to say. I think you have to be very lucky to have a test that is exactly the same as your live.

    My point is, even with a change control and testing system in place, how can you be confident that a significant change will not affect the live system ( if, like me, your test environment is not the same as Live)

    Any thoughts?...or am I just being too paranoid.

    Regards

    Graeme

Viewing 8 posts - 1 through 7 (of 7 total)

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