Deploying changes to a step in the release pipeline applies the changes to the database at that step.

Overriding Project Options

You can override project settings by specifying different options, either in a GUI dialog or by specifying options on the CLI.

Deploy Using the GUI

You can deploy directly or deploy with options.

Deploy Only

Open the project in the GUI
Click the Plan tab.
Click Deploy.

Deploy with Options

A dialog presents options to override.

Open the project in the GUI
Click the Plan tab.
Click Deploy with Options
In Deploy Options, specify additional options, then click Finish.

Option	Default	Description
Use Contexts	None - no contexts are specified for deployment.	List of contexts to use. Use $all to specify all contexts configured on the project.
Use Labels	None - no labels are specified for deployment.	List of labels to use. Use $all to specify all labels configured on the project.
Deployment Mode
Full Deploy Quick Deploy	Full Deploy	Full Deploy includes a forecast (rules and change simulation). Quick Deploy deploys changesets without a forecast.
SQL Generation
Generate Deploy SQL Script	False	Generate and save the SQL script used to deploy these changes.
Generate Rollback SQL Script for this Deployment	False	Generate and save the SQL script to use to roll back these changes.
Collect Row Counts During Forecast and Deploy
Exact	False	Collect accurate row counts using table scan. This method may be time consuming for large tables
Approximate	False	Collect estimated row counts using statistics. Uses database statistics as the source of information. You need to make sure the statistics are available and updated. The time saved varies, but can be significant for very large tables. See Settings for Collecting Row Counts.
DIsabled	True	Do not collect row counts.
Limited Forecast
Limit	False	If set to true, limit forecasting to only those objects affected by the changes. Otherwise profile all objects in the target database schema. Note that some forecast and post-forecast rules may be skipped when this is true.
Stored Logic Validity Check
Fail Deployments that produce new invalid object errors.	True (fail)	Determines what to do when the Stored Logic Validity Check fails. Both existing objects already in the database and new objects being deployed are checked. warn - print WARN message and continue New objects that fail - print WARN message Existing objects that fail - print WARN message fail - print WARN or ERROR message, depending on objects New objects that fail - print ERROR message Existing objects that fail that were not targeted by a changeset in the deploy operation - print WARN message (7.7 & later) Existing objects that fail that were targeted by a changeset in the deploy operation - print ERROR message

Deploy Using the CLI

To run a deployment, use the deploy command. See the deploy command listing in CLI Commands for the options you can specify.

The command requires a step argument. The example uses Dev.

hammer deploy Dev

Deploy Results

Deploy reports are placed in datical/<project>/Reports, sorted by date.

See Available Log Files and Reports.

Deploying Changes