Database Deployments are Easy with DeployHub
Database deployments should be easy and part of your overall configuration and release strategy. While a database deployment 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 changes in the correct order, no matter how many versions forward or backward it needs to address.
Incremental Processing of Database Deployments
Most database deployments 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 deployments 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. 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. 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 deployments 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.
To begin tracking your microservice death star, sign up with DeployHub Team. This option is based on the open source Ortelius Project. It is provided for free and hosted for high performing development teams who want to manage Services in the new modern architecture.
- FREE Team Sign-up – A hosted version deploys to unlimited endpoints by unlimited users.
- Get Involved in the OS Project –Co-create the best, open source continuous deployment platform available.