DevOps has been pervasive within Application Development for several years, but the database environment is so different and sensitive in nature, making database development a barrier to an end-to-end DevOps strategy.

The most important element of DevOps is continuous change. But the most important thing in databases is stability. Right off the bat there’s a non-match.

Next, changes in application code from one release to another are fairly easy to track. But not so much in databases, especially where PL/SQL is concerned, plus the sensitive nature of schema and data changes.

Then, there’s testing. DevOps favors short release cycles, which require automated testing because there’s so little time for manual testing. But most organizations deploy changes to their databases more slowly and utilize more manual testing.

In short, DevOps adoption is a mainstream approach in app development, but database DevOps is relatively new. It’s not easy to reconcile the two environments and bring them into parity with each other.

But if you can swing it, you’ll successfully streamline development by synchronizing database and application deployments.

Database DevOps adoption

There you are, working under tight project deadlines, revising code written by somebody else, conducting manual testing and reviews, and troubleshooting poorly performing SQL.

How could you NOT want ways to make your processes more agile and simple?

As I mentioned in my previous post, we’ve created an infographic based on the results of a Unisphere Research report, The Current State and Adoption of DevOps. The infographic and report summarize the lessons of companies that are figuring out how to use DevOps to bring the work of database developers into closer parity with that of application developers.

Here are a few insights into how your fellow database developers look at DevOps:

Concerns when planning a database release (p. 18 of the report)

Sometimes you can’t postpone database releases. When application changes require changes to the database structure, application releases often have to wait for those changes to be made. Concerns about multiple applications accessing the data (22%), the schema and data changes I mentioned earlier (20%) and the data coming from multiple sources (19%) arise.

Frequency of changes (p. 19)

How often do you deploy database changes? I’ll bet it’s not several times a day, the way some of your app developer friends can. But do you go to the opposite extreme, like only a few times a year?

The report shows that 46% of respondents deploy a couple of times a month or more frequently. Most of the others deploy once a month or less frequently.

Most important tools (p. 22)

As you think about DevOps adoption, what kinds of tools will be most important? It’s going to take more than a text editor and a version control system to implement DevOps successfully, so consider the tools you’ll use.

As shown in the chart below, survey respondents rated these the top five most important toolsets for the DevOps environment:

1. Deployment (69%)
2. Monitoring (62%)
3. Source control (59%)
4. Issue tracking (52%)
5. Automated test (52%)

Your turn: Get “The Current State and Adoption of DevOps”

Use our infographic and the Unisphere Research report to discover how your peers are starting to tackle the integration of database changes into DevOps processes. The Current State and Adoption of DevOps lets you gauge your progress and make the case for your own database team to move (or move faster) toward bringing database development and release cycles into parity with those in application development.

You have nothing to lose but manual tasks that you don’t really want to perform anyway.

 Download the Report>>