General overview of Liquibase development lifecycle

Hello, and first, please accept my apologies for a basic question, but I am new to liquibase.

 

I am just trying to gather a general overview of how liquibase functions with regards to the software development lifecycle.

 

Here is my current understanding;</div>

Lets say the lifecycle is Local database  -  Test Database  - Production Database

A change is made to a database - lets say a new view and package are created, so the master.xml is updated with an include to run the new xml files to create the view and package.

The Local database is then updated in one of the various ways, such as command line, or ant script.

The changes are commited into the source control repository.

To update the Test Database, we simply need to change the liquibase.properties file with the connection  details to the Test database.

Repeat this process to update the Production database.

 

If something needs to be rolled back at any time, this can be done using the command line, ent etc.The rollback updates the database, ie, it would remove the view and package created above.

But, the source control repository would still contain the xml files for the view and package, and the master.xml would still say to include these files.

 

Is my understanding correct? Am I missing some major important factors here?

 

Many thanks in advance, and again, I apologies the vagueness of this question.

Yes, your understanding is pretty good. 


The main thing I would add is that once a changeSet is committed to your source repository it is generally best to not expect rollback commands to be performed anywhere that has ran it, but rather to add the drop package command as a new changeSet at the end of the changeLog. It is less efficient, but it will ensure the package is removed everywhere and will keep the update process consistent, regardless of when the applied a new version of master.xml.


You can remove the original changeSet from master.xml, but will need to make sure it is rollled back/undone across all databases. It is definitely possible to take this approach, but I generally find it more work and cause for error than it is worth in most cases.


Nathan