Making Database Changes a Tier One Artifact

Economic reality and technology are shortening business cycles. What this means for companies, new and established, is that the windows of opportunity for capitalizing on market trends are shrinking every year.

The solution is to get applications out faster and better. Facebook’s mobile application’s two-week release cycle has set the pace for other companies. We’ve heard from older, more traditional companies that this pressure is forcing strange and unnatural behaviors that are causing their existing application release processes to break. The number one source of friction is the database change process.

At Liquibase, we believe that database changes should be treated as tier-one artifacts in your release cycle. To truly achieve the necessary visibility and traceability with database changes such that they can be managed as part of the larger application release process, it’s necessary to store those database changes in JFrog Artifactory. Doing so allows development and operations teams to provide more nimble support to the business. In turn, it also enhances IT’s ability to support the strategic needs of the business.

Let’s take a step back and remember why we use Artifactory in the first place. Simply put, we need a single source of the truth. Of course, we have that with our source code control, but that’s not the best place to put our applications ready for release. Artifactory provides a mechanism for anyone in the organization to request the latest released version of an application and also include any dependencies required by the new application version.

But, you are not including the database changes. And oversight is causing serious problems.

To illustrate, think of the simplest architectural diagram of your application. I bet it looks a lot like this:

If you’re including your database as part of your architecture, why aren’t you including it as an artifact?

Simply put, your application releases need to be able to do the following:

1. Include all necessary components to run the application on a freshly provisioned environment for development and testing purposes. (Think CLOUD.)
2. Provide an upgrade for a previously deployed version to the current release. (For production with existing data that must be protected.)
3. Provide a rollback to a previously deployed version. (Again, for production with existing data that must be protected.)

Obviously cramming SQL scripts into Artifactory isn’t going to meet these goals. Maybe having a single SQL file that will create an empty schema will meet our first requirement. But, it will fail for upgrades (number two) and rollbacks (number three).

The next step we see our customers take (before using Liquibase), is to have incremental upgrade scripts. The challenge with this approach is that it is impossible to automate. A person will have to verify which SQL script has or has not been run and take action. Moreover, the rollback requirement requires a person to verify that the rollback SQL exists and will work as expected. Thus, a seemingly well-intentioned edict has created a huge overhead for our development and operations teams.

We have solved this problem for very large companies with a combination of JFrog Artifactory and Liquibase.

The first step our customers take is using Liquibase to orchestrate their database changes. We can gather these changes from a variety of sources. Liquibase can consume SQL scripts, take deltas of existing database schemas or provide wizards to create change. Once those changes have been “Liquibased”, the changes can be pushed to target environments with the same toolchain you use to push your application binaries. Using Jenkins to compile source code and put the binary into JFrog Artifactory? No problem! Just use the Liquibase runner plugin for Jenkins. Using an Application Release Automation (ARA) solution with Artifactory? Again, no problem! We support all ARA providers.

All of this helps you go much faster, but you need a solution that allows you to go fast without increasing risk. That is where Liquibase forecast comes in. Liquibase knows the state of all your environments, which artifacts have been deployed where, and it will forecast whether a change will work in that environment (you can’t add a column to a table that doesn’t exist yet in pre-prod!). Liquibase forecast also makes sure that your artifacts follow corporate best practices, standards, and governance without requiring a manual review. Are developers following naming conventions? No creating changes without comments!

Once your Liquibase database changes are stored in JFrog Artifactory, you will find that you can deploy your entire application stack to any environment. You will see an increase in speed coupled with reduced risk and lower costs to manage deployments. Both of these decrease resources we need to dedicate to the change process and maximize our customer satisfaction through timely releases that enhance the user experience.

See other ways that Liquibase is Making Database Change Easy for Developers.