The Definitive Guide to Database Version Control — Part 6

this is part six of a seven part series on database version control. in part one , two , three , four , and five 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.

we will now reveal the correct way to practice database version control in order to maximize value and eliminate risk to the organization.

database enforced change management combines the enforcement of version control processes on the database objects with the 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, which means 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.

[build & deploy on-demand]

how does database enforced change management handle the challenges?

✔ ensures all database code is covered – structure, business logic written in the database language, reference content, database permissions, and more are managed.

✔ ensures the version control repository can act as the single source of truth – the enforced change policy prevents anyone (developers, dbas) using any ide (even command line) from modifying database objects which were not checked-out before and checked-in after the change. this guarantees that the version control repository will always be in sync with the definition of the object at check-in time.

[single process enforcing version control]

✔ ensures the deployment script being executed is aware of the environment status when the script is executing – building (generating) the deployment script when needed (just before executing) guarantees it is aware of the current environment status.
✔ ensures the deployment script handles conflicts and merges them – by using baselines in the analysis, the nature of the change is known and the correct decision whether to promote the change, protect the target (ignore the change), or merge a conflict is easy.

[baseline aware analysis]

✔ generates deployment scripts for only relevant changes – the integration with application lifecycle management (alm) and change management systems
(cms) enables you to assign a reason to the change, as is done in the file-based version control or task management system.

✔ ensures the deployment script is aware of the database dependencies – the sophisticated analysis and script generation algorithm ensures the ddls, dcls, and dmls will be executed in the correct order based on the database dependencies, including inter-schema dependencies.

in addition to the must-have requirements, there are also further requirements, such as supporting parallel development, merging branches, integrating with the database ide, and supporting changes originating from data modeling tools. you must verify that these requirements will be addressed by whichever method you choose.

in the seventh and final part of the series, we round things up and provide an easy-to-use comparison chart of the four methods for managing database changes, and the advantages provided by each.