How to implement the Use Case using liquibase

We are doing a POC to evaluate if liquibase can solve our requirement and trying to understand how the below use case can be handled using liquibase.what is the standard way to make the use case implement.

Please find the use case/scenario below.


Dev Environment the following changes happen in DB.

|T1|Create a new table||||
|T2|add a new column

Update create table script with the new column||||
|T3|update the datatype of a column

Update create table script with the new column||||
|T4|Change the PK of the table
The above 4 changes completed in DEV Environment.


QA Environment the following changes happen in same table

Update create table script with the new column|Applied in QA|||
|T5||Add one more column

Update create table script with the new column|||
|T6||Add a default constraint

Update create table script with the new column|||
|T7|||Applied in Bake||
|T8|||Add a unique index

The above changes happen in QA

PROD| Environment the following steps will happen

Update create table script with the new column|Applied in PROD|

Here, how we create the changelog file for all the use cases. Can any one help.

Sounds like you need some consultancy and training

This should be simple. Create changesets as always and use context to control which steps are executed in all or only certain environments.

I don’t know what file format you are using, but my examples will just be in .sql. You can refactor into other formats as needed, the important part is the structure of the changesets.

--liquibase formatted sql

--changeset BOB:T1-create-table
CREATE TABLE X...

--changeset BOB:T2-add-column
ALTER TABLE X add column...

--changeset BOB:T3-update-column-datatype
ALTER TABLE X modify column...

--changeset BOB:T4-change-pk
ALTER TABLE X change constraint...

--changeset BOB:T5-add-column
ALTER TABLE X add column...

--changeset BOB:T6-add-constraint
ALTER TABLE X add constraint...

--changeset BOB:T7-??
I have no idea what "applied in BAKE" means

--changeset BOB:T8-add-index
CREATE INDEX X_INDX...

My example use pseudo-code for the actual SQL. Each changeset runs as a independent transaction, and is tracked separately in each database target.

Once a changeset has executed it should never be modified unless it is repeatable SQL (for example: CREATE OR REPLACE).

Typically all changes to DEV should also be applied to QA. In your example it’s not clear if T1-T4 are being applied to QA, and if T5-T8 are applied to DEV. I’m assuming T1-T8 have already been applied to DEV, and T1-T4 have been applied to QA when T5-T8 are applied to QA.

That’s the best I can provide with the limited details in your example.