The Definitive Guide to Database Version Control — Part 7

this is part seven of a seven part series on database version control. in part one , two , three , four , five , and six we reviewed how the methods for creating software evolved into agile and devops, what separates the database from application code and the challenges that must be addressed when managing database changes.

we then went through the most popular methods being used and the shortfalls of each, and revealed the correct way to practice database version control in order to maximize value and eliminate risk to the organization.

summary

using manual processes for database changes means a substantial risk to the database and the valuable data it holds. two of the most popular methods provide no automation at all and leave the database far behind.

utilizing simple compare and sync to manage database changes also does not answer many of the specific challenges of the database because it does not utilize the version control repository when performing the compare and generating the ddl script. for that reason the version control repository does not act as the single source of truth.

another problem that simple compare and sync runs into is, that because the information is stored in the alm, cms, or version control repository, which is external to the compare & sync tool, it compares the entire database and shows the differences, generating relevant and irrelevant deployment scripts.

most critically, simple compare and sync does not ensure the deployment script handles conflicts and merges them.

database enforced change management , on the other hand, combines enforcement of version control processes on the database objects with generation of the deployment script when required, based on the version control repository and the structure of the environment at that time.

this approach uses “build and deploy on-demand,” meaning the deploy script is built (generated) when needed, not as part of development. this allows for efficient handling of conflicts, merges, and out-of-process changes.

the database component has special requirements, and therefore creates a real challenge for automation processes. in the old days, when there were only a few releases per year, it was common and understandable to invest time manually reviewing and maintaining the database deployment scripts. today, with the growing need to be agile and provide releases faster, the database must be part of the automation process. developing sql scripts, developing xml scripts, or using simple compare & sync are either inefficient and/or risky approaches when it comes to automation. the most effective method is to implement database enforce change management.

comparison table:

to see how database enforced change management can enables agile development, continuous integration and delivery for the database, schedule a free demo now.