Agile Development and the Modern Database

Page 1 of 2 next >>

Q&A with Shay Shmeltzer, Director of Product Management for Oracle Cloud Development Tools

The concepts of Agile methodology and continuous delivery have become popular in software development, yet they are somewhat less mature among DBAs and database developers. Shay Shmeltzer, director of product management for Oracle Cloud Development Tools, discussed how database administrators (DBAs) and SQL developers can take advantage of newer development approaches while also dealing with the unique challenges that exist in the world of database development.

Agile methodology and continuous development have become standard in today’s fast-paced application delivery cycles. Is that also true in the area of database software?

In some organizations, the database team is an integral part of the Agile team, but we still see many cases where the database team is a bit separate from the rest of the Agile team. DBAs are very protective of their databases and, in many cases, they maintain a “lock” on that resource,

acting as the gatekeeper in terms of any database structure and code changes. This creates situations where developers are stuck waiting for the DBA to apply changes they require while developing solutions outside the database, which results in delays in the Agile process.

How mature is Agile methodology, version management, and continuous delivery in the world of DBAs and database developers?

It’s definitely not as mature as it is with “regular” developers. One of the reasons is that unlike regular software, with databases you have to maintain state, which is the data that represents the current state of the information you have stored. You can’t just replace the runtime artifact directly, such as a table. If you have a table with data in your database and you want to add a column, you are not going to just change the creation script of the table and then drop and re-create the table, or the whole database. Instead, you need a new script that alters the table.

Now you might end up with two versions of scripts—one for existing databases and one for creating databases from scratch. You then need to know which script to run on which table. A fresh database might require you to run the modified CREATE script, while an existing database might require running an ALTER script.

This article is the first installment of a six-part series by editors of IOUG SELECT and DBTA on "DevOps and the Modern Enterprise" with three articles on the SELECT website and three articles on the DBTA and Big Data Quarterly websites. 

Add to this the challenge of not always knowing which scripts have run on which database, and you can get into a very messy situation. So, code version management is a bigger problem for DBAs and much more complex than it is for regular developers. Continuous delivery [CD] also becomes tricky in that case, as you need additional logic involved in the automation process to know which script to use where. What we do see is the rise of specific solutions for version management and database migration solutions targeting this space.

How can DBAs and SQL developers using databases keep their database and code current and in sync with the work they’re doing during development?

One of the approaches we see emerging is the use of utilities that are able to track the status of a specific database instance. They track the scripts that ran on a database instance and then know which other scripts need to run in order to get the database to the most recent status. Some of these solutions can also roll back your database to a specific state.

This means that you are not modifying scripts you’ve already created but rather just adding scripts that modify the database status. Utilities such as Liquibase and Flyway are examples of such solutions.

What are some of the newest database features that developers should take advantage of in order to stay ahead of the curve when developing new applications?

Redefinition is one feature that complements schema changes and utilities, such as the ones I mentioned.

To read the second article in this series, "What is DevOps?" by Tim Boles, go to  

Page 1 of 2 next >>