I recently spent two days consulting with a company on their database development and deployment processes. They are a small, capable, team of developers, database developers and a DBA who have embraced the idea that they need to be able to automate their deployments. I wasn’t in there to teach them much of anything, but to help walk them through what the possibilities were for their deployments. It was a great experience and I learned a lot. They recognized that it was time to change what they did and how they did it in order to achieve greater efficiencies. They recognized that, while they were successfully building and deploying their databases (a capable team, remember), they were experiencing pain that they could alleviate. Like Peter, it was a time for change.
I think, like Peter, people get freaked out by the idea of changing. The concept of “if it ain’t broke, don’t fix it” is not a crazy or dangerous one to have. Unfortunately though, processes can be both functional and broken if they’re just functional enough. Think about how long it takes you to prepare for a database deployment. Think about how well tested your deployments are before you get to production. Think about the number of mistakes you’ve introduced to your production environment. Think about the changes that you haven’t done because getting them into production would be too hard or take too much time. These are all indications of pain. If you’re hitting lots of pain, well Peter, it’s time to change.
The good news is, like Peter, there’s lots of support out there for you. For example, coming up in London, Friday the 16th, Redgate is hosting SQL in the City. It’s a fantastic event (and yeah, I’m saying that even though I work for Redgate). We’re going to be showing off our tools, especially some of the tools that can help you get your database lifecycle management processes under control. Want to get started on that change so that you can reduce the pain in your deployments? Then click here to register.
Can’t make it to London? How about Seattle? We’re taking the show on the road. We’ll be there on the 26th of October. Click here to sign up.
“…just functional enough…”. Yeah – we used to call it “good enough engineering”. It was hard to convince management to invest time/effort/$$ in improvements. So I’d say that your capable team had some pretty good management, too.