Database Updates are Easy with DeployHub
Database updates should be easy and part of your overall configuration and release strategy built into continuous delivery. While a database update is not a microservice you may need an update to a database as part of a microservice release. DeployHub handles this for you. DeployHub allows you to include in your microservice deployments the calling of Components that can perform database updates such as alters, create, inserts, updates, index and delete. DeployHub allows you to define a roll-forward or rollback script to handle the case if something needs to be backed out, or you need your database to jump to a much higher version. DeployHub’s database deployment engine sees everything as independent objects, handled incrementally. This means it can apply database updates in the correct order, no matter how many versions forward or backward it needs to address.
Incremental Processing of Database Updates
Most database updates are nearly always delivered as deltas – SQL “alter” scripts that make changes to the previous version of the database schema. So if all you’re doing is deploying the next version of the application package then that works fine. However, what if you’re database updates are using versions that are several releases ahead of what’s in the environment? This can easily happen if the test and production environments are “pulling” specific application versions as opposed to having them “pushed” via a Continuous Delivery process, or they simply prefer not to take every release that is delivered from the developers. Now, just applying the alter script that is associated with this application version won’t work in any environment that doesn’t contain the previous version of the application.
Picture an application package (“My Application”) that is up to version 6. Lets say we have a microservice that is a WAR file (for simplicity sake). The application has two components, the WAR file and a Database component that contains alter scripts that roll the database schema forward. Here are what the last 4 versions look like:
So version 3 has a new version of the WAR file. Version 4 has a new version of the WAR file and a database alter script that adds a column to a table. Version 5 only changes the database (it amends a stored procedure which uses this new column). Version 6 applies a new change to the WAR file.
Now, in a Continuous Delivery process the test cluster being targeted will receive each new version of the database update. So when version 4 is deployed, the cluster will receive version 4 of the WAR file and the alter script will be executed to add the column to the table to complete the database update. Then when version 5 is deployed, only the DB alter script will run (alter.sql;2) in order to amend the stored procedure. The WAR file is not deployed since the server already contains version 4 of the WAR file. When version 6 is deployed, only version 5 of the WAR file is deployed. This is exactly what we want.
But now what happens when we move to the next environment, like testing? In testing, the team can do a “pull” when they’re ready to accept the new version of the application. So they pull “My Application Version 6” into their test environment.
But what happens if the test environment is currently on version 3? Well, for the WAR file, there’s no problem – there’s a difference in the component version for the WAR file so the new version is deployed. But what happens to the database? There are no alter scripts associated with version 6 of the application – but without applying alter.sql;1 and alter.sql;2 the database schema is not going to be valid for use with myapp.war;5. The testing will fail – not so much “falling at the first hurdle” as “falling in the paddock”.
DeployHub uses database updates that are based on deltas to cure this issue. DeployHub identifies the components that represent the database changes and get them to be applied in sequence for each interim version. In that way successive database “deltas” are applied in order to roll the database forward to the correct schema version before the required version of the application is deployed. This same logic can be used to go in reverse for a rollback.
So, in our case, going from version 3 to version 6 would deploy the following components:
So DeployHub would deploy (and run) alter.sql;1 to add the new column, then alter.sql;2 to amend the stored procedure and finally, deploy myapp.war;5. Deltas mean we do the minimum required to get the application version to the desired state.
See it in Action
- A Microservice Service Catalog for Incident Response
- Domain Driven Design Catalog to Tame Microservice Sprawl
- Microservice Architecture and Your Logical Application
- Microservice Configuration Management
- Continuous Deployment and DevOps at Scale
- Register for DeployHub Team
- Reverse Proxy Setup for SaaS Deployments
- DeployHub Team User Guide
- The Hipster Store Tutorial
Ortelius Open Source Project
All Continuous Delivery and DevOps Blogs
- Continuous Deployment Blogs
- Understanding a Microservice Pipeline
- Microservice Continuous Integration – Where’s the Build?
- Working with Helm for your Microservices Releases
- Kubernetes Pipeline Challenges
- Managing Embedded Configurations
- Questions and Answers on managing a K8s Pipeline
- Running Safe Blue / Green Deployments
- The DeployHub Jenkins Plug-in
- Setting Up the Jenkins Plug-in
- The DeployHub CircleCI Orb
- Creating a Continuous Feedback Loop
- Release Agents – the Enemy of Continuous Deployments
- DeployHubs Release Architecture
- Why we need Application Packages for CD
- Agentless Deployments with DeployHub’s Engine
- Version Jumps and Tracking
- Microservice Configuration Management
- Database Updates in Your Continuous Delivery Process
- Database DevOps and DeployHub