This approach tracks changes made during each release and can be useful as a tracking and auditing mechanism. This is popular for teams with database changes not tracked in a source code repository before adopting Liquibase. 

Though no history exists for each object, this approach enables change tracking moving forward.

Below is what a directory structure organized by release may look like:

Best practices

✅ Dedicate a top-level directory for all database scripts, such as sqlcode, to point to the path to the database changes in Liquibase.

✅ Use a Liquibase root (main) changelog file inside the top-level sqlcode directory to define the order in which the release subdirectories will traverse. This eliminates the need for Liquibase to make multiple calls to a changelog file in each object's subdirectory. Instead, a single call is made to the root changelog file.

1. • If your application (or data team) deploys to multiple schemas or databases, it would be desirable to create schema or database directories. Place release subdirectories inside each schema or database directory. Include a changelog file in each schema or database directory.

   • From the root (main) changelog file, use include tags to guide Liquibase to child changelogs located in each release subdirectory. From here, use include tags again to point to child changelogs located in each schema or database subdirectory:

Visit the sample GitHub repository organized by releases. Download the code if you want to use this repository structure. 

What to do next

Branching Strategies