[SNAP] [PIANO PLAYING]
So in the previous video, we set the scene really by talking about the prevailing market conditions. What are the things that are driving businesses to move to an agile approach and embrace DevOps? And what are the advantages of moving to that?
We see a lot of success. But equally, for companies that decide to stick with the traditional way of things, what's the downside? And so in this video, we're going to talk about, the first step is database change management.
If a database development team has followed the same processes for decades, it's very difficult to break out of that cycle and adopt something which is a different way of doing things. But actually, it's not as hard as you might think. We're not really fundamentally changing the way that the database developer works.
We're simply taking some of the aspects, which actually may be quite laborious to do-- things like code reviews, and testing-- and figure out a way in which we can simplify the process of doing those things, and getting to a point where they become repeatable. And if they become repeatable, that means that they can be automated. So the ultimate goal is automation. Automation is the key, from a technology standpoint, to database DevOps.
Some of the main challenges of bringing in these traditional database processes into a DevOps type of process is, number one, some of those processes may not be happening at all. A good example actually is testing. And what I mean by testing is functional unit testing of database procedural code.
A lot of organizations are invested in database procedural code. It's been there for many, many years. The reason that companies don't want to change-- because that's a significant investment. And they don't want to have to go through the pain of defining everything, or the business logic inside the application. That's a lot of extra work to do.
So they've decided that they're going to keep all that procedural code. But in a lot of companies, it's never been tested, or at least not tested properly. So we have to think about, how are we going to test it? How are we going to reduce technical debt?
What I mean by that is making sure that the code that you build and maintain continues to be maintainable in the future by somebody who didn't actually write the code. If you can't do that-- if you have a high technical debt-- it restricts your ability to change that code quickly when you need to.
And the other one I'd say is source control. So source control systems are used by application teams a lot. And in the most part, in my experience, most of database development teams also use source control. It's really important in a DevOps scenario, because a source control system is your system of record. It records who changed what, why, and when, and records all those changes for auditing purposes if necessary, or if you need to roll back to a prior state if necessary.
Not managing database development means that it's going to be very difficult to move forward with an automated process. And if we can't automate some of those processes, then that's going to make it very difficult to reduce the time it takes to deploy changes into production. And therefore, it's going to reduce the likelihood that the business will see added value as quickly as they would like to see it.
So one good example would be one company that I worked with tried to reduce their release cycles on the database side from eight weeks down to two weeks. That's what their business was asking them to do. And that's what forced them into thinking about, how are they going to start embracing that?
They were using version control, as I mentioned-- source control systems. They have no functional test for any of their procedural code. And they didn't really have any objective, repeatable standards. So that really was the first step in the journey for them.
Quest software has a solution called Toad. It is a suite of database development tools that enable developers to very easily integrate their source code changes with the source control system, or reverse control system, like GIT, or subversion. It enables them to easily define unit tests for procedural code, even though that code already exists, simply by running the code and storing those tests in a repository.
And it also has a rules-based system for code quality, where a company can decide which rules reflect their corporate quality standards and then reuse those time and time and again for the future. And then, once you've got to that point, we can then take those and automate them as part of a traditional automated build and deployment system that a lot of companies already have invested in.
Moving from a traditional approach to an automated approach requires, first of all, making sure that you have your database development teams have access to a source control system. A lot of organizations already have them. And like I said, most database development teams already use a source control system. So that's the first thing, because then you've got the ability then to capture changes and store a history of all those changes moving forward.
Using a source control system is also a trigger for an automated build process-- that's something the application development teams already do-- and then think about what procedural codes you have that needs to be tested. Think about what code quality standards you've got. And it's very easy to set these things up inside of the [? towed ?] product line. Once these things are set up then, they lend themselves immediately to becoming part of an automated building deployment process.
So if I was to list the dos, I would say, start small. So don't bite off more than you can chew. Start on
07:33