Using agile processes for software development has many benefits, but perhaps the biggest is that it lowers the risk associated with changing code. By focusing on small, focused tasks, you have a better chance of hitting the nail right on the head, as opposed to a waterfall methodology that incorporates many massive changes into one big honkin’ release. And, even if you get a bit lost in your agile project, it still only involves small functionality or small change.

Now compare this to operations, which is used to getting out those big releases once every six months or once a year. It has not been set up to deal with change every few weeks. When you do the large releases, the risk of change is huge, because those releases usually involve a lot of changes (and therefore have more quality assurance to do), but there are simply more things that can go wrong. This is what gave birth to what we now call DevOps.

This is the case if you’re working in traditional code, whatever the language, but not if you’re doing database development. One of the ways developers lower the risk of change to their code is through the use of version-control systems. But database developers haven’t raced to adopt similar processes and tools when doing their jobs.

Yaniv Yehuda is cofounder and CTO of a company called DBmaestro, which is seeking to bring the DevOps approach to database development and deployment with enforced change management.

“When you deal with databases, they do not follow the same concepts of traditional code, let’s say of Java or .NET, or anything which is file-based, because the database for the operating system is like a big blob,” he said. “It’s not something operations can see into. Internally, we know it’s composed out of schema, structures like tables and the like; there is code within it. Pure code, logic, SQL code that can be in the form of functions or procedures that run within the database for mainly efficiency, not going back and forth to the application, and there is the lookup content, content that influences the behavior of the application, being data by itself. It might be some kind of content table, and based on that content, the application knows how to behave in a certain way or in another. All of these things need to be managed as would any other resource within the application. But these don’t fit straight into the version-control system or the risk-control system that regular code would fit into.”

But, Yehuda added, that doesn’t mean version-control concepts cannot be applied to working with databases. The notions of check-in/check-out, and compile and debug, are equally applicable, even though database coding and testing are done outside the pale of code development best practices.

“How a change is handled within a version-control system is check out an object, modify the script, take the modified script, and check it back in, and that’s it,” said Yehuda.

“Working with the database is not working with scripts. You need to test your changes and you need to debug it. So as a part of it, after you check the script, you need to make sure you have the right script in the database. You need to compile, need to debug, get to the final revision where it’s working. Once it’s working, you need to extract the script, get it back into the version-control system, check it in, and then you’re happy.

“But these are two unconnected processes. There are a lot of pitfalls. You might not have taken the latest revision from the version control. So you run something old in your database, you reach some working state, but when you check it in, you’ve overwritten somebody else’s changes. You might have extracted the changes but not put it in the database, or make everything run perfectly in the database but forgot either to extract the right script or check it back into the version-control system. This is essentially a non-enforced process… Two developers taking out a procedure, one edits the function, one edits something at the end, the first one puts it back into the database and the second one puts it in the database, and it overwrites the previous one’s changes, and no one even knows if it got lost.”

David Rubinstein is editor-in-chief of SD Times.