Skip to main content
Database Updates in Your CD Process

Database Updates in Your CD Process

By 01/14/2020December 2nd, 2022Continuous Delivery

database

Database Updates are Easy with DeployHub

Database updates should be easy and part of your overall microservice 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. Let’s say we have a microservice that is a WAR file (for simplicity’s 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:

Deployment Updates with Version control in Applications

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 that 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 gets 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:

deployment version control and application package

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

Further Reading:

Next Post
Close Menu