Database DevOps for Continuous Delivery
Database DevOps is long overdue. Automating database DevOps via the CI/CD pipeline has been attempted with manual intervention and scripts, but these manual practices cannot keep up with DevOps at Scale. As we move into microservices, with the possibility of hundreds of database changes occurring daily, database DevOps becomes more critical. As a DBA, I’m sure you’re not yet intimately involved in building out the Continuous Delivery pipeline. I’m here to tell you that you should be and database DevOps should be a part of it. As you already know, your impact to the software release process is no different than a developer’s. The question you need to ask yourself is, “why aren’t my database deployments and updates incorporated into the CI/CD pipeline along with all the other changes?”
Part of the problem is what you are updating. In the standard continuous delivery process, a binary is simply copied over the older binary. That’s not the case with a database update. As you well know, you must modify the existing object, the database itself. Instead of a copy, you are running alter scripts, and they need to be changed or backed out of in a specific order. This is the core of Database DevOps.
In other words, managing a database is far different than managing a binary. It’s the nature of the beast that makes it problematic for you to participate in continuous database updates. While you certainly can use a CI/CD engine like Jenkins to execute your alter script as part of an automated process, your updates must be applied sequentially. You can’t just stomp over the top of your database like you can a binary. And with immutable microservices, you may be managing multiple versions of a table supporting multiple versions of a microservices. The complexity is epic and needs full configuration management visibility and database DevOps automation.
DeployHub and Database DevOps
DeployHub includes database DevOps as part of its core features. DeployHub performs database updates using an incremental processing engine and tracks versions of microservices to versions of your schema. With DeployHub, you create an Application Package based on Components. Components can be anything, including your database updates. When the software is released, the Application Package is interrogated based on the individual Components, and each Component is versioned, which allows DeployHub to track the differences between all Components in a software release, including the database schema updates.
When you create a database Component, you specify the alter script to move forward and to roll back. And there is more. DeployHub manages updates based on the Component versions and applies your database updates incrementally or rolls them back incrementally in the correct order. This database DevOps process is the real secret sauce of DeployHub. With DeployHub, you join in the automation and DevOps at scale driving your database updates as part of the CI/CD pipeline.
DeployHub’s Key Features
- Publish and Catalog Microservices
- Blueprint your application’s logical view
- Release and Track Microservices
- Manage Database Deployments
- Microservice Continuous Integration – Where’s the Build?
- What is Configuration Management?
- How to Navigate the Deathstar
- Working with Helm for your Microservices Releases
- On Versioning your Container Content
- Versioning Lambda Functions
- How to Use a Domain Driven Design
- Versioning Applications
- Why we need Application Packages for CD
- Agentless Deployments with DeployHub’s Engine
- Version Jumps and Tracking
- How are Microservices and Applications Related?
- Why upgrade to Pro?