Modernize database change management to support DevOps

Hello, and welcome to CBR TV. My name is Jon Bernstein. Today, I'm joined by John Pocknell, who is senior product marketing manager for database solutions at Quest. John, great to have you here. We're going to talk about database management. Let's start by talking about it in the context of DevOps. Increasingly popular as a way of doing application delivery and service. What are the database considerations? So database considerations are quite an interesting aspect of DevOps. Because until recently, database isn't one of the things that was factored into the whole DevOps conversation at all. At least if it was, it was like, that's too hard. Data is risky. Changing data is risky. Changing data structures is risky. But the thing is that the traditional waterfall approach, which is a fancy way of saying it's slow and cumbersome, a manual approach, is actually risky too. Because what happens in a waterfall approach is your ability to make the changes into the production system takes quite a long time. A lot of companies take somewhere between eight weeks and three months to make those sorts of releases, during which time you've got a lot of changes that all have to hit production all at the same time. That's very risky. Because if something goes wrong-- and the likelihood is that it will-- you have a lot of changes to back out of and fix and then redeploy them. So there's a lot of good reason to change the way that things have been done traditionally. So when it comes to agile, what is the problem that database is causing to organizations making the most out of agile development? I guess because traditionally the changes that have been made to a database have tended to be manual-- followed manual processes-- they involve things like manually testing the code changes, manually doing code reviews, those peer reviews. So somebody checks my code to see if it looks OK. The problem with that is it's very slow and cumbersome. And it's very subjective. It's just one person's opinion versus another one. It doesn't lend itself to becoming automated. So the key, the critical thing, to changing the way that you've done database development to having it become agile is automation. You can't automate a process that you don't have in place. So if you're not doing any testing at all, then you don't have a vehicle by which you can move towards automation. And I kind of make this parallel. Look at the way that application development is done. Even over the last 20 years, it's followed that kind of approach. It's automated approach. You've got well-established built automation processes that involve automatic testing of code and quality reviews. It's all automated. And really, that's the way that you have to look at the way you do database development. So if you do a database development, you've got procedural code that needs to be tested and reviewed to make sure you're not introducing defects. You have to figure out, how am I going to, first of all, do it if I'm not doing it at all? And then, how do I automate that so that it becomes part of a continuous integration process? So you spelt out the barriers and some of the ways that you might address those barriers. Talk to me more about how you overcome the obstacles. So we have to try to not disrupt too much in the way that developers do their job. Developers like to write code. They like to innovate. They like to think of new ideas. So we don't want to disrupt that creativity. But what we do want to do is look at ways in which we can make their life easier by taking out the humdrum of doing manual code reviews, and even thinking about testing, which for developers is real pain. So if we can simplify the process of testing by making it easy for developers to create functional tests, the tests that their code is doing what it's supposed to do, and come up with some rules-based system, which is objective, which can be applied consistently across all the code changes. So you've got some measure against which you can say, is my code good to go, or is it not? And then, thirdly, have some way of using a system of record to audit all of the changes that are ever made. Because if something goes wrong, you've got to figure out who made that change, why did they make it, and when? And second, you've got to be able to potentially back out of a change if necessary. So you can only do that if you're using a source control system. John Pocknell, thank you very much. Thank you.