The future of database DevOps

Foundry is Redgate’s R&D division. Part of our remit is to look further into the future. We do that by keeping an eye on things that might indicate a change in what you need from our products (eg, a new problem), or a development in technology (eg, a better way of solving an existing problem). We want to develop a clearer understanding of the future of database DevOps.

In this post we’re reflecting our assessment of the status of DevOps for the database, giving you a behind-the-scenes look at how we’ve arrived at this assessment and setting out our direction.

We want this to be a conversation with you: maybe you’re interested in contributing your experience, perhaps you don’t agree with our assessment, or you could just be curious and want early access to anything new that we develop as a result. Whatever the reason, we’d like to talk to you, so sign up and help shape the future of database DevOps.

The database DevOps landscape

Database DevOps concerns are wide ranging. They affect you, your team and your entire organization.

Our research with domain experts and technology industry analysts set out to answer three questions:

  • What set of concerns does database DevOps cover?
  • What’s covered by Redgate’s product capabilities already?
  • What new technology could impact each of these concerns?

The outcome of this research gave us a ‘map’ of the database DevOps landscape:

The map of each DevOps concern (in black) revealed areas of interest based on capabilities that exist with Redgate’s current suite of products (in red), and technology that may prove useful in increasing capability (in blue).

We’ve made four observations that we think are interesting enough to pursue:

  • Testing is conspicuous through a relative absence of coverage.
  • Team collaboration is a recurring theme across multiple concerns.
  • Provisioning is a theme that occurs throughout dev and is impacted by containerization.
  • Rollback/forward is a concern that’s not well-supported with technology.

During our research, we became aware of three additional pieces of information regarding changes to the context in which teams are implementing database DevOps:

  • Database environments. The drive towards microservices means that applications backed by multiple databases separated by concern are becoming the norm.
  • Deployment frequency. Changes to production databases need to be made more often in order to keep up with the demand from the organization to get value to customers sooner.
  • Contributors. An increasing number of people within teams and organizations as a whole are contributing to database changes.

Database provisioning appears to be affected both by changes in technology (notably containers), and by changes in context (particularly frequency of need and complexity of environment). As a consequence, our continued research into the future of DevOps for the database will begin here.

The ability to provision a database environment is a core capability that’s required throughout the development lifecycle. We believe that the easier it is to create complex environments and manage their use, the less likely the database will be the blocker for achieving your organization’s ultimate outcome of delivering new value to your customers quicker.

We’re setting out to understand whether our belief is true and, if it is, what form a solution to these problems could take. We’re doing this in a project we’re code-naming Project Spawn.

Again, we want this to be a conversation with you, so get involved by signing up to the research project.

Tools in this post