Loading…
This event has ended. View the official site or create your own event → Check it out
This event has ended. Create your own
View analytic
Thursday, May 25 • 5:30pm - 6:15pm
Making Database Changes a Tier One Artifact

Sign up or log in to save this to your schedule and see who's attending!

Feedback form is now closed.

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 release processes to break. The number one source of friction is the database change process.

At Datical, 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 release process, it’s necessary to store those database changes in JFrog Artifactory. Doing so allows our development and operations teams to provide more nimble support to the business. In turn, it also enhances IT’s ability 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 you serious problems.

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 Datical DB), 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 create 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 Datical DB.

The first step our customers take is using Datical DB to orchestrate their database changes. We can gather these changes from a variety of sources. Datical DB can consume SQL scripts, take deltas of existing database schemas or provide wizards to create change. Once those changes have been “Daticalized”, 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 Artifactory? No problem! Just use the Datical DB 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 Datical DB forecast comes in. Datical 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!). Datical 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 Datical DB database changes are stored in 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 provide enhance the user experience.


Speakers
avatar for Robert Reeves

Robert Reeves

CTO, Datical
As Chief Technical Officer, Robert Reeves advocates for Datical’s customers and provides technical architecture leadership. Prior to co-founding Datical, Robert was a Director at the Austin Technology Incubator. At ATI, he provided real world entrepreneurial expertise to ATI me... Read More →


Thursday May 25, 2017 5:30pm - 6:15pm
Meritage Carneros Salon A 875 Bordeaux Way, Napa, CA 94558