Overview

The normal flow of deployment goes through stages. Depending on your environment, you may have more or fewer stages. 

Development > Test > Production

Developer Workflow

During development and test you may find problems with the original SQL scripts that were packaged and deployed to test. A failed test might indicate a need to remove or replace changesets that were deployed to Test and make adjustments in the Development environment. These adjustments might require the developer to:

• Ignore a changeset - Abandon changeset in place and prevent it from being deployed further.  If needed, you can recover it (unignore) later. 
• Clean up  a previously deployed changeset - Ignore deployed changeset, create changesets to clean up any changes that were created.
• Replace a previously deployed changeset - Replace the changes in a changeset with other changes. This usually implies running a cleanup first.
• Use versions with changesets - Deploy only the latest version of a changeset. This capability is intended for use with programmatic parts of the database (stored logic). 

To enable this capabilty, new changeset attributes are added to all changesets generated from a SQL script. 

Comparison to Rollback

The normal release workflow allows you to deploy and roll back changesets throughout a project pipeline. Rollbacks can be automatic for some changes or be performed by custom rollback scripts you supply. See /wiki/spaces/DDOC59/pages/795673649. 

However, the development workflow is for making changes to the changesets (and other changesets they affect).  When you use the -ignore, -cleanup, and -replace scripts, they mark the original changesets so that they are no longer deployed. Changes are anticipated at these stages in a pipeline.  They are not expected in later stages. 

See Rollback Script Handling for more information on how to work with existing rollback scripts in a development workflow. 

Example: ignoring a deployed changeset. 

To signal a change, you create a special file using the same base name as the original SQL script, apply a suffix (for example, -ignore), and place it in the same directory where you placed the original file. 

• invoice_columns.sql
• invoice_columns-ignore.sql

When invoice_columns-ignore.sql is processed, the ignore attribute is set on all of the original changesets produced by invoice_columns.sql.  The changesets are no longer deployed.