Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Challenges of Database Change Deployment Processes — Part 2

DZone's Guide to

The Challenges of Database Change Deployment Processes — Part 2

In part two of our four part series on database deployment automation, we will look at the challenges of automation for the database, the various solutions, their shortfalls, and then reveal the proven best practices.

· Database Zone
Free Resource

Download the Guide to Open Source Database Selection: MySQL vs. MariaDB and see how the side-by-side comparison of must-have features will ease the journey. Brought to you in partnership with MariaDB.

This is part two of a four part series on database deployment automation. In part one we examined the evolution of Agile and DevOps. We will now look at the challenges of automation for the database, the various solutions, their shortfalls, and then reveal the proven best practices.

DevOps is a natural evolution of the software industry, it’s not a revolution.

One way of dealing with the database challenge is to force the database into the generic process: create scripts out of database objects and store them in the traditional version control.

That creates other challenges, namely:

  1. Scripts in the version control system are not connected to the database objects they represent as these are two separated systems. Coding and testing of the database code is done at the database side, disconnected from any of the coding best practices (check-in, check-out, labels, etc.), and prone to all illnesses of the "old days" such as:
    • Code-overrides in the database are common as there is nothing to prevent it.
    • Scripts are required to be taken from the version control before starting the code on the database, to prevent working on the wrong version; but there is nothing to enforce that.
    • Scripts do not always find their way to the version control system, as it depends on the developer to remember to do so.
    • Out of process updates go unnoticed, etc.
  2. Scripts are manually coded, prone to human error, syntax error, etc.
  3. To have everything you might later need, you actually have to save two to three scripts for each object; the actual code of the object, the upgrade script, and a roll-back script.
  4. Scripts are hard to test in their entirety, as you make changes to a single object, while someone else makes a change to another single object, and running in any order would usually raise errors due to faulty dependencies between these scripts that need to run in a specific order.
  5. If a script is developed as a single script to represent the entire update, instead of a single change, it can deal with dependencies, but is much harder to deal with project scope changes. It is a big list of commands.
  6. And these scripts, unless super sophisticated, are unaware of changes made in the target environment during the time passed from their coding to the time they are run, potentially overriding production hot-fixes, or work done in parallel by another team.
  7. Content changes are very hard to manage. Metadata or lookup content does not practically fit into the version control. In most cases, they are simply not managed.

Download our popular eBook: In Database Automation We Trust


In part three of the series we will look at the standard "compare & sync" solution and its shortfalls.

Interested in reducing database costs by moving from Oracle Enterprise to open source subscription?  Read the total cost of ownership (TCO) analysis. Brought to you in partnership with MariaDB.

Topics:
database change management ,devops ,database ,dbmaestro ,database automation

Published at DZone with permission of Yaniv Yehuda, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}