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.sqlinvoice_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.
Do not use more than one suffix when working in a development workflow (-ignore, -unignore, -replace, -cleanup, -rollback). For example, when you update a myscript-rollback file, you update it in place. Do not create a myscript-rollback-replace script. It causes an error during packaging.
It is important to maintain consistent case in workflow file names!
When creating a new workflow file it is important to maintain file name casing that is consistent with the original file. MYSCRIPT-ignore.sql will not match myscript.sql.
If you are using git, you may have to run the following command to configure your repository to enforce consistent file name case: git config core.ignorecase false