According to Microsoft, DevOps is “the union of people, process, and products to enable continuous delivery of value to our end users.” The definition doesn’t mention any frameworks or specific tools, and it’s more about communication and culture than any technology. That said, automation and tooling are critical components of DevOps as it helps organizations improve delivery of software. Unfortunately, in many organizations, changes to the databases are still made outside of the DevOps pipeline.

In the 2019 State of Database DevOps survey, 85% of respondents reported that they had already adopted a DevOps approach or planned to in the next two years, and only 34% include the database as part of an automated build and deployment process. (The results from the 2020 survey will be available soon!) When the database is not included, features that depend on database changes will be delayed.

Organizations are embracing DevOps, but it’s more difficult to bring the database along. While there are exceptions, you can’t just delete a production database and replace it with a fresh copy. It’s much easier to replace a service or executable file than it is to make database changes, and extra care must be taken to avoid data loss and corruption.

The classic way of implementing database changes is by providing a lengthy script to the DBA and expecting them to quickly validate it and deploy it. Deploying massive database changes to production a few times a year is both risky and difficult. One of the tenets of DevOps is to release small changes frequently. Small database changes should still be validated by a DBA, but they will also be tested earlier and automatically in the pipeline during the build, unit testing, staging, and QA processes. Many steps in the pipeline require realistic copies of the database with all sensitive data masked. The right tools can make this possible.

Historically, database administrators have been accountable for stability and, therefore, resist changes while developers are expected to quickly provide new features that often require database changes. These expectations are diametrically opposed. In a successful DevOps organization, all teams share responsibility for the end goal instead of their own isolated areas or “technical silos” to be successful.

DevOps culture tears down technical silos by improving communication between teams. The first step to accomplishing this could mean creating cross-platform teams or embedding DBAs in the dev teams on occasion, for example. Breaking down these silos means moving away from the “us vs them” mentality and the “blame game” when issues come up.

DevOps is not something you can buy or implement by flipping a switch. It’s a gradual process starting with culture. To truly implement DevOps, the database must be included.