deployPackager.groovy

Create changesets from SQL scripts and deploy the changesets.

USAGE

hammer [<hammer-options>] groovy deployPackager.groovy [dbdef=<dbdef-name> | pipeline=<pipelineRef>] [manifest=<directory> | <JSON-file>] || scm=true] [labels=<label-list>] [contexts=<contexts-list>] [showDebug=true] [invalidsAction=warn|fail] [dbdefDeploy=true|false] [commitPrefix="<text>"] [preview] [createDatabaseBackup=<true|false>] [invalidsAction=<warn|fail>] [cleanup]

REQUIREMENTS

Either dbdef= or pipeline= must be the first option in the command. Only one is allowed. Changes are packaged and deployed either to the DbDef specified or the first (leftmost) DbDef in the pipeline.

Either manifest= or scm=true is required. Only one is allowed.

The deployPackager.groovy command and its options are case-sensitive.
When specifying labels and contexts that should be added to change sets produced by deployPackager.groovy DO NOT include dashes before the argument names
- Correct: hammer groovy deployPackager.groovy pipeline=PIPELINE1 scm=true labels=label1,label2 contexts=context1,context2
- Incorrect: hammer groovy deployPackager.groovy pipeline=PIPELINE1 scm=true --labels=label1,label2 --contexts=context1,context2

OUTPUT OPTIONS

--log <dirname> - Log directory. Default location is <project-directory>/Logs.
--report <dirname> - Reports directory. Default location is <project-directory>/Reports

OPTIONS

dbdef=<dbdef-name> - Name of the DbDef to use. When this option is used, changesets use contexts set in the DbDef along with any specified by the contexts option. Use when you are working with feature merges.
pipeline=<pipeline-name> - Name of the pipeline to use. Changes are deployed into first dbdef in the pipeline, which should be the REF database. Use when you are working with pipeline merges.
manifest= - Specify a directory name or a JSON file to use as the source of SQL scripts. A deploymentPackager.properties file must be present at the project root directory. It specifies the
scm=true - Get the SQL scripts to process from an SCM system. A deploymentPackager.properties file must be present at the project root directory. It specifies how to access the SCM system.
labels - Comma-separated list of labels to apply to the changesets created. Expressions are not supported.
contexts - Comma-separated list of contexts to apply to the changesets created. Expressions are not supported.
showDebug - Default false. Set to true to get additional logging messages.
invalidsAction=<warn|fail> - Default warning. Pass this value to the deploy commands used during packaging. Determines what to do in response to testing for invalid stored logic. If warn, then failed tests print a warning message and deployment continuse. If fail, then print an error message and halt deployment and packaging.
dbdefDeploy - Default true. Set to false to disable forecast and deploy.
commitPrefix="<text>" - Message to be placed at the beginning of the commit comment when Deployment Packager commits changes to an SCM system. Intended for use as a hook to trigger automatic actions by the SCM system.
preview - Include this option to generate a report of what would happen. No packaging or deployments are actually performed. When you are managing database backups manually (databaseBackupMode=on_demand), using this option with createDatabaseBackup=true causes the database to be backed up upon successful preview.
createDatabaseBackup=<true|false> - Create a new database backup. Valid only when databaseBackupMode=on_demand in deployPackager.properties. Used when you are managing database backups manually rather than allowing Deployment Packager to back up the database during every deployment. Use with preview to perform a database backup and do nothing else. See Managing Database Backup and Restore.
invalidsAction=<warn|fail> - Override the storedLogicValidityAction project setting for this deploy. Default behavior is 'warn' which will cause the Deploy to flag deployment as warning for new invalid stored logic. 'fail' will mark the deployment as failure.
cleanup - Cleanup mode will release locks on the tracking table, clean up any utility objects created in the database as part of packaging and restore the RefDB to it's last known good state. Use it when a Packager job was prematurely terminated.

DATICAL SERVICE OPTIONS

Use the following options to specify a project stored in Datical Service. Place them as hammer command options, before the groovy keyword.

daticalServer - the hostname or IP address where the Datical Service is installed. Note that they are not interchangeable. The one to use is established when you run Initialization Wizard during installation.
daticalUsername - user name defined in the Datical Service. Use the DATICAL_PASSWORD environment variable to provide the password.
projectKey=<projectRef> - projectRef is a project name or project key

NOTES

The Deployment Packager gets SQL files to process from one of two sources:

SCM system ("SCM mode"). Use the deployPackager.properties file to specify how to access a repository through a source control management system.
Manifest file ("manifest mode"). Specify either a directory of JSON files or a single JSON file to use.

Merge methodologies in SCM mode:

Feature merge - used when development teams use feature branches in source control. Features are then merged into a release pipeline.
Pipeline merge - used when development teams work on multiple releases at a time. A pipeline is defined for each release. Merges are performed across the pipelines. For example, a change introduced into the pipeline for the September release can then be merged into the pipeline for the October release.

EXAMPLES

Datical DB - See Running Deployment Packager (CLI examples)

Datical Service - See Using Datical DB Hammer Commands with Projects in Datical Service (Packaging Example)

OUTPUT

Different output is produced depending on whether packaging succeeds or fails.

During the process you will see multiple deploy operations recorded in the log on the way to a completed change deployment.

See Output from Deployment Packager.