Grant Fritchey (2/17/2014)
I'm going to take a guess and assume that you're not talking about my session called "Best Practices for Database Deployment" because I get into a lot of what you're talking about there.
Hi Grant! That's exactly the one I'm talking about. I kind of wish it had diverted into a whole talk about management instead.
I make a huge point of saying that DBAs are not the special snowflakes that they think they are and that process, whatever it might be, absolutely has to apply to them equally.
Well you're preaching to the choir and it's all common sense to me. But I think you've misunderstood the direction I'm coming from. Argh, so frustrating for us both 🙂
From what you've said I almost feel like you are implying that process is handed down on tablets from management, where IME (probably much smaller shops than yours) it's more likely to be something that bubbles up from employees and only after a bloody turf war against the old guard of manual processes.
Management gets stuck in the middle. The elders are saying everything is fine when it clearly isn't. The relative newbies are obviously just trying to play with new *cough 14 year old cough* technology.
And I think it comes down to management not understanding that it's quite difficult to build a modern application without source control because every build is a complete state. It's very easy to run a database development and deployment process manually because all those databases are maintaining their own state and you're only sending out many hand written error-prone scripts.
And so I wanted some more ideas on explaining things in that way to management, to garner support, against those who think manual processes are good enough.
I sure hope I haven't dug a hole now.
In short, I don't think DBAs are good at the development/deployment aspects of our job. We're great at the "protect production" part, but let that override the other. We need to do both.
I care about both so we're on the same page there. I swear I'm not an ingrate 😛