Invitation and roundup from Grant Fritchey.
Implementing DevOps with databases presents a unique set of challenges. However, just because something might be hard doesn’t mean that it shouldn’t be done.
I had the opportunity to work with a team of developers, database developers and DBAs under a management team that all agreed on the common goal we had, delivering more, better performing applications, faster. We didn’t know it at the time, but we were doing DevOps.
DevOps gets a bad name because, well, the problems that DevOps sets out to solve, poor communication, bad teamwork, dysfunctional development and badly configured and maintained processes, are done by the same team that attempts to implement DevOps. However, they look on it as a purely mechanical switch that they throw, assign some poor person to the role of DevOps Coordinator (or something) and then maintain the status quo in regards to their culture and approach to software. Shocking that implementing this doesn’t work.
Then, toss in databases with the whole issues around persistence, and things go nuts.
This then, is my choice for T-SQL Tuesday. How do we approach DevOps as developers, DBAs, report writers, analysts and database developers? How do we deal with data persistence, process, source control and all the rest of the tools and mechanisms, and most importantly, culture, that would enable us to get better, higher functioning teams put together? Please, tell me your DevOps stories.