How to Automate the Database for DevOps Success

| July 6, 2017 | 3 Comments

How many times have you had to stop your release just to ask a DBA to make changes to a database so your deployments would be successful?

How many times have you gone looking for a DBA to make a small change to a database just to be told you have to wait because they’re on a more pressing production issue?

What did these time lapses cost you?


In large enterprises, these gaps in deployments actually cost companies thousands—if not hundreds of thousands of dollars—each year. And why? Because there’s no database automation in their pipeline at all.

The reasons for this usually boil down to a few functional (or dysfunctional) issues:

  • Siloed tasks and teams.
  • Old “it’s my domain and you can’t touch it” mentality.
  • We can’t do anything with databases. Only DBAs can do that work.
  • And finally, the technical construction of the database architecture itself precludes automation.

Application Release Automation

The question is how to address these issues. Enter Application Release Automation (ARA) and DevOps Database automation. ARA specifically calls out the need for automation at all layers of your technology stack, including the database. DevOps database automation tools, such as Datical DB, make it possible. We’ll talk more about Datical in a bit. But first, some technical concepts and details to help you get started.

The database is holding organizations back

Database as Code

Databases contain both structural elements, such as the schema, stored procedures, and triggers, as well as data that’s already stored in the database. While the structural elements may be easy to change in a development environment, those same changes in production take an entirely different set of rules.

Applying Continuous Delivery principles to production databases is challenging due to the reasons outlined above, but it’s worth the effort because of the ongoing efficiency gains. Continuous Delivery in the pipeline allows developers to check database changes into the source repository, or to treat Database-as-code, thus enabling the automation of database changes. It also allows an orchestration tool in the pipeline to “call” those scripts to make the changes to the database.

Live Webinar: The Role of Automation in the Journey to Continuous Delivery

Join us to learn the importance of automation to successful DevOps
 adoption, how DevOps initiatives scale in the enterprise, and how the combination of application and database release automation improve DevOps outcomes.

Automation leads to standardization of database changes across the pipeline, from development and testing, to QA and production. The same change (or rollback) is applied to every phase and is tested thoroughly before reaching production. By shifting left, the quality of the database changes increases as the database moves towards the production environment.

The term Database Lifecycle Automation refers to adding a level of maturity to the systems development lifecycle (SDLC). The result of this maturity is why we’re seeing database tools (such as Datical DB) emerge. Unfortunately, this very maturity is usually ignored because of some of the functional issues discussed above. That’s why educating IT teams about database automation tools is so important for fully implementing Continuous Delivery into the enterprise.

Automate the deployment of database changes

Using Datical DB for Database Automation

Datical DB is a database automation tool that lets you enable database configuration changes and integrate them into the DevOps pipeline. Treating database changes as code enables your Continuous Delivery process and your transition to true DevOps. Datical’s DB helps you bring your database into your Continuous Delivery process by:

  • Enabling integration with other automation tools through a single changelog to describe database changes and by allowing changes to be made from the command line.
  • Automating database upgrades and the generation of DBA-ready scripts that DBAs can manually invoke.
  • Enabling self-service by allowing databases to be created anywhere along the release process, from development through production, due to its support for a variety of target database types.
  • Making the database change process transparent (who, what, and when) by generating JavaDoc-style documentation and placing the documentation into the changelog.

Wrap Up

Yes, you can do DevOps Database Automation. It will take some effort to overcome the perceived obstacles, but with a little education about the tools available and the long-term benefits—automated changes, faster time to delivery, self-service, and more—its importance to Continuous Delivery should become clear.

Editor’s note: This post was originally published on November 3, 2016.


Sunil Mavadia

About the Author ()

Sunil Mavadia is Director of Customer Success for XebiaLabs. A former customer, Sunil brings deep experience with DevOps initiatives, having lead major DevOps transition projects with his previous company. At XebiaLabs, Sunil works closely with customers to ensure successful implementations of the XebiaLabs DevOps Platform.

  • Tim Coote

    This article is fine at the high level. However, data are different: if you change the schema, you’ve got to change the historical data, too. If the release fails, you’ve got to be able to reverse the schema migration (rather than just release version n-1 of the application and fail over).

    Have you got any tooling to help with Blue/Green deployments – it would be very helpful to support the db state comparison challenge of a B/G deployment.

    • Hi Tim,

      You are right about the data. I can’t speak on Daticals behalf but we have Blug/Green Deployment technology right here: https://docs.xebialabs.com/xl-release/how-to/perform-blue-green-deployments.html. Hope this helps.

      • Tim Coote

        Excellent start. However, I think that the definition of B/G misses something important that Sam Newman used to articulate in connection with stateful (e.g. dbms) updates: the transition of the read/write mechanism:
        a/ blue dbms handles all r/w operations, sync state to green
        b/ write operations update both blue and green
        c/ read operations switch to green, continue to write to both
        d/ blue retired

        during stages b/c blue and green states are compared for consistency. I was hoping for tools to help with this comparison process..

        The example quoted is the simple transition for ‘stateless’ services. The difference between the stateless and stateful transitions shows why it’s helpful to strive to minimise the stateful components 😉