Databases are the hidden bottleneck to DevOps, says Redgate

It's not as hard as you think to bring databases into the DevOps process, argues Tom Austin

Databases are often excluded in the drive to adopt DevOps. In the excitement of developing applications more quickly by standardising and automating the production pipeline, the harder-to-change databases are much more difficult.

"It's the secret we don't talk about," said Tom Austin, pre-sales engineer at Redgate, speaking at the Computing DevOps Summit today. "If we have to change the database, we have to wait."

The reason that the database is a bottleneck is simple: it's because databases contain data.

"Application code is pretty easy to change, but with a database ultimately the data has to persist," said Austin. "Plus, there's the problem of database drift - changes made in production - and then there's the difference between production data and static data. What happens when there's data that you might wish to change in development that you also need to deploy somewhere else? How do we source control database code?"

Another issue is the human side, how to involve the DBA in the team.

"This is tough sometimes," Austin said. "Often the best first step is to give the DBA visibility into the changes that you're ultimately going to make."

Before taking the plunge, though, it's vital to take the right preparatory steps.

"Any transformation comes with pain so it's important to have buy-in across the organisation, said Austin. "You need the right group of people to come together. It's hard to do quickly but it's worth it because future changes will be much easier."

Fortunately, building databases into the DevOps strategy is not as difficult as it might seem, said Austin, because according to Redgate's surveys 75 per cent of developers routinely code both applications and databases, so few new skills will be needed. Moreover, the basic processes in the software development lifecycle are no different: code control, continuous integration and release management.

"The people are the same - except that you have the DBA in the loop, the processes are the same and the production is the same," Austin said.

The differences come in with the way that databases are treated at the source control. There are two alternatives approaches to making changes to databases: state-based deployment and a migration-based approach. State-based approaches have the benefit of version control and easy roll-back, whereas migration techniques allow automation earlier in the process as well as dependency ordering.

Austin argued for a hybrid approach, which is where Redgate's tools sit.

"You can carry on using Visual Studio for a state-based approach and tools like DbUp and Flyway for migrations and Redgate provides a middle way," he said.

As a Microsoft Partner with its tools integrated into Visual Studio 2017, Redgate has a strong focus on Microsoft SQL Server but it also covers Oracle databases. In response to an audience question, Austin said the firm is looking at supporting Postgres, but has no plans as yet to provide tools for NoSQL databases.