Development Process

• Use in the DEV and TEST Stages
• Do not use on the PROD Stage

Use this capability to make changes in a feedback loop between DEV and TEST.

1. Deploy to DEV
2. Deploy to TEST
3. Testers communicate changes needed and testing results back to developers. 
4. Developers use the changeset management capabilities to amend/replace/version changesets and redeploy to TEST
5. Continue until ready to deploy to PROD
6. Analyze the net effect of tested changes and use new changesets to deploy to PROD. 

Use Cases for Development Workflow

The Liquibase Enterprise Knowledge Base contains User Guide: Developer Workflow, which describes how to move from your first SCM repository check-in through various activities in the Development Workflow. 

Usage with SQL Script Types

Deployment Packager distinguishes SQL script types. When using SCM tools, you place scripts into a directory structure according to type. Deployment Packager processes the files according to type. It packages by type in two general ways:

• Process and archive. Done for "non-rerunnable" types: DDL folder or packageMethod=CONVERT, DDL_DIRECT folder or packageMethod=DDL_DIRECT, DATA_DML folder or packageMethod=DATA_DML, SQL folder or packageMethod=SQLFILE, SQL_DIRECT folder or packageMethod=DIRECT.  These changes are typically only deployed once.  Use ignore/unignore or cleanup/replace with these types.
• Processed in place. Done for stored logic folders FUNCTION, PACKAGE, PACKAGEBODY, PROCEDURE, TRIGGER, VIEW, or packageMethod=STOREDLOGIC.  Use versioning with these types.  These changes are stored in place and can be modified and deployed multiple times. 

You should be familiar with how Deployment Packager processes scripts in order to use the changeset-management tools effectively. 

See Other Means of Getting Changes into the Release Pipeline for details on the directory structure in SCM repositories and script execution order. 

Ignore and Unignore

• Use on any change scripts.
• Cleanup and replace internally set the ignore attribute on changesets they affect. 

Cleanup and Replace

• Use on changes that are deployed once and archived
• Do not use on stored logic and other changes that are maintained in place and deployed multiple times. 

Version

• Use on changes that are maintained in place and deployed multiple times, such as stored logic. 
• Use the versionStrategy setting in the metadata.properties file to specify deployment behavior (deployAll is the default, deployLatest can be specified). 

Use Small Scopes for SQL Scripts

The changeset-modification tools work best with SQL scripts that contain a small number of changes. 

When an application change calls for a multiple object changes in the database schema, it is better to break those changes into several small SQL scripts rather than use one large one. This is particularly true for changes deployed to DEV and TEST, when it is important to be able to make changes quickly in order to converge on passing test criteria.