Redgate has updated its Flyway platform for applying DevOps workflows to database platforms to now provide deeper integration into command line interface (CLI) tools and integrated developer environments (IDEs).

In addition, the Flyway platform now enables state-based deployments using scripts that can be generated based on a specific schema.

Finally, Redgate is also adding options that enable DevOps teams to choose whether they want to include backups as baselines, automate the backup process altogether or never allow any type of shadow database.

Max Drobot, group product manager at Redgate, said these latest additions are intended to make it simpler for software engineering teams with varying levels of maturity to start automating the management of databases within the context of a DevOps workflow. Rather than trying to create the perfect process, it’s now simpler for DevOps teams to more easily experiment with automating database deployments without increasing risks, he added.

While DevOps engineers and database administrators (DBA) often need to work closely with one another, each of these teams has historically developed a separate culture around different classes of tools. Since it first launched Flyway, Redgate has been making a case for a platform that helps narrow that divide by enabling DevOps engineers to, for example, spin up a database when needed versus waiting for a DBA to have the time that would otherwise be required.

That approach doesn’t eliminate the need for a DBA, but it does serve to reduce the overall level of friction that often exists between DevOps teams and DBAs, noted Drobot.

The need to reduce that friction will become that much more pressing as the amount of data that needs to be incorporated into the next generation of artificial intelligence (AI) applications continues to exponentially increase, he added.

Additionally, DevOps teams as part of building and deploying more secure applications will also eventually need to programmatically apply policies and guardrails to the data being accessed by their applications, noted Drobot.

Managing databases has, of course, become more challenging as the number and types of them has steadily increased. Provisioning and managing databases using legacy manual processes is simply no longer tenable, he said.

Many organizations are already embracing platform engineering as a methodology for managing DevOps workflows at scale, so it’s now more a question of when database operations will become more centrally managed within the context of a software development lifecycle (SDLC).

In the meantime, DevOps teams might want to review how application developers are selecting databases for building applications today. All too often, rather than adhering to corporate standards, those decisions are based more on personal preference. In fact, it’s not uncommon for IT teams to find themselves spending time migrating an application developed on one database to another that the organization actually supports.

Each organization will, of course, need to decide on its own to converge the management of DevOps and database operations but given the pace at which modern applications are now being developed and updated in the age of AI, the amount of pressure being applied to achieve that goal is only going to continue to increase.