I thought I would share my ‘beginner’ experiences with liquibase. In particular, I think I’m starting to understand there are different ‘operation modes’ in how you would leverage Liquibase depending on your environment.
Rather than listing out operation modes, let me summarize my experiences of liquibase in a ‘SqlFile’ operation mode, and see if people can help provide similar experiences.
Operation Mode: SqlFile
Preface: this is often a beginner, or introductory, mode to slowly bring Liquibase into an environment with minimal culture/procedure changes.
Target Environment/Audience: Environments where database changes are done using native db tools and the deliverable is always change scripts (raw sql scripts, often with native syntax for the target database).
Liquibase Users: Only the ‘control’ person, or the person responsible for tracking changes to the database.
Limitations: SqlFile operation mode provides no quality controls from liquibase, and changes using the raw script files need to be pre-tested before they are used by liquibase. Rollback feature option still exists, but requires a seperate change script to manually run the rollback feature. Database-specific.
Gains: Creates a ‘master’ sql change file per promotion, which includes the DATABASECHANGELOG on the deployed databases to have a way to see what changes have been applied. Can also still use the SqlDoc option to generate change documentation from the control files (the db-change.xml files). Reduces the amount of culture/environment change to only the ‘control’ person.
Description of using this mode:
This mode only focuses on creating ‘control files’, or db-change.xml files, for each individual change script file. If large change script files are generated, it may be advantageous to breakup the change script file into smaller files, so each change can get its own db-change.xml control file.
The control files use the normal changeSet identifiers, but does require manual tracking of the unique ID’s, as well as manual creation of the xml file itself.
-
this is a change script for updating a database column
Then, using the ‘master’ control file (and assuming consistency in checkouts of your raw sql change scripts), you can create a single master SQL file for normal SQL updates (assuming your environment still requires all raw SQL to run all things):
-
liquibase.bat --defaultsFile=targetEnv.properties --changeLogFile=db.master-1.1.xml updateSQL
With this master sql file, you can now promote your environment using a SQL file, but have the DATABASECHANGELOG updated to know what changes have been applied to the database as well as use the SqlDoc option to create change documentation.