The current trend for software development teams is to adopt a continuous delivery approach based upon DevOps and agile development techniques. DevOps is relatively a new term, coined in 2009, defining software engineering practices that combine software development (Dev) and software operations (Ops). The general idea is not really all that new, but the adoption of agile techniques and modern tooling to automate software delivery is. The goal of DevOps is for developers and operations personnel to collaborate throughout the entire service lifecycle, from design through development and into production.
A DevOps approach results in small and frequent code changes that can significantly reduce the lead time for changes, lower the rate of failure, and reduce the mean time to recovery when errors are encountered. With such benefits that can accrue, it is no wonder that DevOps and continuous delivery are gaining in popularity. Today’s development organization migrates more frequent changes into production than ever before.
While all of this sounds like a good thing, and it can be, there are challenges. One of these challenges is when an application change also requires database changes. Indeed, the 2017 State of Database DevOps report cites database development as lagging behind application development in terms of continuous delivery.
The problem, as I see it, is that many DevOps shops, emphasize the “Dev” over the “Ops” causing important operational aspects to be overshadowed by development concerns. And the “Ops” part is where database management and administration lives.
Far too often, control of the application delivery process is driven by development, sometimes without the traditional control and oversight of the DBA group. Without the expertise of the DBA the delivery and integration process can fall apart because database change cannot be treated exactly like application change.
Application delivery usually involves copying code and executables from one environment to another. By contrast, the database is an entire configuration in each environment and changes get migrated. Each environment might be different (however so slightly). And differences can drift in due to things like performance optimizations, emergency changes, and so on. Furthermore, consider application packages where access paths are determined at bind time. Database access paths are not (and cannot be) copied from the development environment. Without an experienced DBA to assist, guide and, indeed, administer the process, problems will arise.
Sometimes developers are given free rein to make database changes in the test or development environment. This can encompass simple things like adding a table, column or index; or it could be more complex, requiring an object to be dropped and re-created. Every DBA knows that dropping one database object can have a cascading effect, dropping and revoking other objects and privileges. But most developers are not as keenly aware of the wide impact of such changes.
In a test environment, complex changes that drop and re-create structures may be tolerable because business users are not impacted, only other developers. But trying to do the same thing in production can cause a significant outage and perhaps even data loss if performed improperly.
When application changes rely on changes to database structures, these changes should be tightly coupled to the application changes that drive them. If the program code expects a new column to be there to function correctly, then you do not want the new code to be moved to production without the new column… and the opposite is also true. DevOps for the database must include not only making the changes, but also backing them out when necessary.
As the continuous delivery model for applications gains momentum and acceptance, a tighter integration between application and database change is required. Integration and expertise is required both at a technology level and at a personnel level. DBA-level expertise is needed on development teams to help guide and implement changes appropriately. Delivery of software that combines application and database changes, developed and managed in an integrated manner, is imperative for DevOps success. Furthermore, automation of all of these steps is crucial and required for database-enabled applications using DevOps practices and procedures.