Working with the command line and Docker
Published 02 October 2020
Deployment Suite for Oracle has been replaced by Redgate Deploy - Oracle. This page is therefore no longer being updated. For the latest documentation, please click here.
The Redgate Change Control command line and Docker containers are still in preview and the API is therefore still subject to change.
When installing Redgate Change Control, the command line executable will be automatically added to the PATH environment variable so it can be used directly from your console, for instance by running rcc --help
. The docker image can be obtained from here.
Verbs
Each of the verbs below takes an additional set of common arguments:
Short | Long | Required | Description |
---|---|---|---|
--IAgreeToTheEula | REQUIRED | By using this option you consent to the Redgate EULA. | |
-v | --verbose | OPTIONAL | Increase logging output for debugging purposes. |
-q | --quiet | OPTIONAL | Suppress logging output except for error messages. |
-f | --format | OPTIONAL | Specify the format of the output. If not set, the default is to provide a human-readable output and to print log messages as they happen. If set to "json ", the output will be a JSON object and any log messages will be stored in that object. |
Currently the human-readable format has not yet been implemented so all data is returned as json.
init
Creates a new Redgate Change Control project configuration file based on the supplied parameters.
Arguments
Short | Long | Required | Description |
---|---|---|---|
-l | --projectLocation | REQUIRED | Path to the directory in which to initialize the project. |
-n | --projectName | REQUIRED | Name of the project to initialize. |
-m | --migrationsLocation | REQUIRED | Path to the directory where the migration scripts will be kept. |
--devSourceType | REQUIRED | The type of the development source. This can be "Database" or "ScriptsSource" (if using a Source Control for Oracle project). | |
-s | --schemas | REQUIRED | Comma-separate list of database schemas to include in the project. |
-f | --force | OPTIONAL | Flag to indicate whether to overwrite an existing project configuration file in the project location if it exists. |
--devUsername | SEE DESCRIPTION | The username to use connect to the development database (Required if --devSourceType is "Database ") - can be specified here or in the environment variable RCC_DEV_USERNAME . | |
--devPassword | SEE DESCRIPTION | The password to use to connect to the development database (Required if --devSourceType is "Database ") - can be specified here or in the environment variable RCC_DEV_PASSWORD . | |
--shadowSourceType | REQUIRED | The type of the shadow source. This can be "Database" or "ScriptsSource" (using a shadow scripts source is an experimental feature). | |
--shadowPath | SEE DESCRIPTION | The path to the shadow scripts source (Required if --shadowSourceType is "ScriptsSource ") | |
--shadowUrl | SEE DESCRIPTION | The jdbc url for the shadow database (Required if --shadowSourceType is "Database "). | |
--shadowUsername | SEE DESCRIPTION | The username to use connect to the shadow database (Required if --shadowSourceType is "Database ") - can be specified here or in the environment variable RCC_SHADOW_USERNAME . | |
--shadowPassword | SEE DESCRIPTION | The password to use to connect to the shadow database (Required if --shadowSourceType is "Database ") - can be specified here or in the environment variable RCC_SHADOW_PASSWORD . |
Output
A json object with the following structure:
{ path: string, -- Absolute path to the project .conf file. projectId: string -- A GUID representing the unique project ID (also saved in the .conf file). }
This command writes per-user settings to a settings folder in the user's home directory. For the docker container, you'll need to create this file yourself or modify the main project file with the dev/shadow details. See Creating a new project for more details on per-user settings.
generate-baseline
Creates a baseline migration script based on a given target database schema and saves it to the project. If working with a development database, this command will also run flyway baseline
to set the schema version.
If using a shadow scripts folder, this command will reset the shadow to match the expected baseline state.
Arguments
Short | Long | Required | Description |
---|---|---|---|
-P | --project | REQUIRED | The path to the project's |
-t | --target | REQUIRED | The jdbc url for the target database to use to calculate the baseline script. |
--targetUsername | REQUIRED | Username for the target database connection - can be specified here or in the environment variable | |
--targetPassword | REQUIRED | Password for the target database connection - can be specified here or in the environment variable | |
--devUsername | SEE DESCRIPTION | Username for the development database connection (Required if using a development database) - can be specified here, in the .conf file or in the environment variable | |
--devPassword | SEE DESCRIPTION | Password for the development database connection (Required if using a development database) - can be specified here, in the .conf file or in the environment variable | |
--shadowUsername | SEE DESCRIPTION | Username for the shadow database connection (Required if using a shadow database) - can be specified here, in the .conf file or in the environment variable | |
--shadowPassword | SEE DESCRIPTION | Password for the shadow database connection (Required if using a shadow database) - can be specified here, in the .conf file or in the environment variable | |
-b | --baselineVersion | REQUIRED | The schema version to set the baseline to. |
-d | --baselineDescription | REQUIRED | The name for the baseline migration script, excluding |
-f | --force | OPTIONAL | Flag to indicate where to overwrite any existing baseline script. |
Output
A json object with the following structure:
{ path: string, -- Absolute path to the baseline .sql migration file saved in the project. }
compare
Compares databases or scripts folders (generated by Source Control for Oracle) to determine a set of changes that can be scripted out.
Arguments
Short | Long | Required | Description |
---|---|---|---|
-P | --project | REQUIRED | The path to the project's |
--devUsername | SEE DESCRIPTION | Username for the development database connection (Required if using development database) - can be specified here, in the .conf file or in the environment variable | |
--devPassword | SEE DESCRIPTION | Password for the development database connection (Required if using development database) - can be specified here, in the .conf file or in the environment variable | |
--shadowUsername | SEE DESCRIPTION | Username for the shadow database connection (Required if using shadow database) - can be specified here, in the .conf file or in the environment variable | |
--shadowPassword | SEE DESCRIPTION | Password for the shadow database connection (Required if using shadow database) - can be specified here, in the .conf file or in the environment variable |
Output
A json object with the following structure:
{ databaseComparison: [ { id: string, -- The comparison id of the difference differenceType: string, -- The type of the comparison difference (e.g. "only in source", "only in target", "equal", "different") objectType: string, -- The type of the object (e.g. "Function" or "StoredProcedure") objectInSource: { name: string, -- The name of the database object schema: string, -- The database schema of the database object definition: string -- The sql definition of the database object }, -- The object as it exists in the source database objectInTarget: { name: string, -- The name of the database object schema: string, -- The database schema of the database object definition: string -- The sql definition of the database object }, -- The object as it exists in the target database } ], reconnectionDetails: { dev: string, -- The absolute path to the source database snapshot file shadow: string, -- The absolute path to the target database snapshot file } }
This command creates snapshots of the database state and stores them in a temporary folder. These snapshots get reused for the generate command, so when using the docker container, you currently need to create a volume bind for the /tmp folder. This ensures the database snapshots are persisted between calls to the rcc CLI.
generate
Generates a set of migration scripts based on the changes selected from the comparison output.
Arguments
Short | Long | Required | Description |
---|---|---|---|
-P | --project | REQUIRED | The path to the project's |
-s | --source | REQUIRED | The path to the snapshot file representing the comparison source. This is returned from |
-t | --target | REQUIRED | The path to the snapshot file representing the comparison target. This is returned from |
-c | --changesToInclude | REQUIRED | Comma-separated list of changes to include when generating the scripts. The comparison difference ids are returned from |
-b | --isBaseline | OPTIONAL | Flag to indicate if the scripts being generated are for a baseline (Default = false). |
--devUsername | SEE DESCRIPTION | Username for the development database connection (Required if using development database) - can be specified here, in the .conf file or in the environment variable | |
--devPassword | SEE DESCRIPTION | Password for the development database connection (Required if using development database) - can be specified here, in the .conf file or in the environment variable | |
--shadowUsername | SEE DESCRIPTION | Username for the shadow database connection (Required if using shadow database and not using a database for development) - can be specified here, in the .conf file or in the environment variable | |
--shadowPassword | SEE DESCRIPTION | Password for the shadow database connection (Required if using shadow database and not using a database for development) - can be specified here, in the .conf file or in the environment variable |
Output
A json object with the following structure:
{ migrationScript: string, -- The sql definition of the migration script. programmableObjects: [ { type: string, -- The type of programmable object (e.g. "Function" or "StoredProcedure"). script: string, -- The sql definition of the object. name: string -- The name of the programmable object. } ], automaticallyIncludedDependencies: [string] -- list of the names of the objects included automatically due to required dependencies }
save
Saves a set of migration scripts to the project. If working with a development database, this command will also update the redgate_schema_history
table to mark the saved scripts as applied.
Arguments
Short | Long | Required | Description |
---|---|---|---|
-P | --project | REQUIRED | The path to the project's |
--devUsername | SEE DESCRIPTION | Username for the development database connection (Required if using a development database) - can be specified here or in the environment variable | |
--devPassword | SEE DESCRIPTION | Password for the development database connection (Required if using a development database) - can be specified here or in the environment variable | |
--versionedMigration | OPTIONAL | JSON string representing the versioned migration to save. The JSON should have the following structure: { script: string, -- The sql definition of the script. version: string, -- The version number of the migration script. description: string -- The name of the migration script (excluding `.sql`). } | |
--programmableObjects | OPTIONAL | JSON string representing the list of programmable objects to save. The JSON should have the following structure: [ { type: string, -- The type of programmable object (e.g. "Function" or "StoredProcedure"). script: string, -- The sql definition of the object. name: string -- The name of the repeatable migration script (excluding `.sql`). } ] |
Output
A json object with the following structure:
{ savedMigrationScript: string, -- The absolute path to the saved migration script. createdProgrammableObjects: [string] -- List of absolute paths to all newly-created repeatable migration scripts. modifiedProgrammableObjects: [string] -- List of absolute paths to all modified repeatable migration scripts. removedProgrammableObjects: [string] -- List of absolute paths to all deleted repeatable migration scripts. }
apply
Deploys migration scripts that were written outside Redgate Change Control and manually added to the project directly to the development database. This command is only available when working with a development database.
Arguments
Short | Long | Required | Description |
---|---|---|---|
-P | --project | REQUIRED | The path to the project's |
--devUsername | SEE DESCRIPTION | Username for the development database connection - can be specified here, in the .conf file or in the environment variable | |
--devPassword | SEE DESCRIPTION | Password for the development database connection - can be specified here, in the .conf file or in the environment variable |
Output
There is no output from this verb.
update
Updates the Redgate Change Control project configuration file with the specified values.
Arguments
Short | Long | Required | Description |
---|---|---|---|
-P | --project | REQUIRED | The path to the project's |
--devUrl | OPTIONAL | The new jdbc url for the development database. | |
--shadowUrl | OPTIONAL | The new jdbc url for the shadow database. | |
--shadowScriptsFolderPath | OPTIONAL | The new path to the shadow scripts folder. | |
--devUsername | SEE DESCRIPTION | Username for the development database connection (Required if using a shadow scripts source) - can be specified here, in the .conf file or in the environment variable | |
--devPassword | SEE DESCRIPTION | Password for the development database connection (Required if using a shadow scripts source) - can be specified here, in the .conf file or in the environment variable |
Output
There is no output from this verb.
repair
Repairs the schema history table in the development database. This can be used to assist with repairing the history table after a failed migration, or an external change to the migrations in your project.
Arguments
Short | Long | Required | Description |
---|---|---|---|
-P | --project | REQUIRED | The path to the project's |
--devUsername | SEE DESCRIPTION | Username for the development database connection - can be specified here, in the .conf file or in the environment variable | |
--devPassword | SEE DESCRIPTION | Password for the development database connection - can be specified here, in the .conf file or in the environment variable |
Output
There is no output from this verb.
status
Retrieves the migration and validation status of the project.
Arguments
Short | Long | Required | Description |
---|---|---|---|
-P | --project | REQUIRED | The path to the project's |
--devUsername | SEE DESCRIPTION | Username for the development database connection - can be specified here, in the .conf file or in the environment variable | |
--devPassword | SEE DESCRIPTION | Password for the development database connection - can be specified here, in the .conf file or in the environment variable |
Output
A json object with the following structure:
{ total: number -- Count of the total number of migrations in the project pending: number -- Count of the number of pending migrations in the project failed: number -- Count of the number of failed migrations in the project successful: number -- Count of the number of successful migrations in the project future: number -- Count of the number of future migrations in the project missing: number -- Count of the number of missing migrations in the project repeatable: number -- Count of the number of repeatable migrations in the project undo: number -- Count of the number of undo migrations in the project versioned: number -- Count of the number of versioned migrations in the project validationError: bool -- Whether an error occurred during validation }
version
Prints the version information for RCC and Flyway. No additional arguments are required.
Output
A json object with the following structure:
{ rccVersion: string -- The version of RCC flywayVersion: string -- The version of Flyway used by RCC }
reset
This verb is used to reset the state of the shadow scripts folder back to the project. In order to do so, RCC cleans the target database before applying all project migrations to this database. It then uses this as a reference to repopulate the shadow scripts folder.
Dangerous
This operation erases all data and objects not captured in your migrations, and is non-reversible. Only use this verb if you're confident you understand the risks.
Arguments
Short | Long | Required | Description |
---|---|---|---|
-P | --project | REQUIRED | The path to the project's |
-t | --target | REQUIRED | The target database JDBC URL to reset. |
--targetUsername | REQUIRED | Username for the target database connection - can be specified here or in the environment variable | |
--targetPassword | REQUIRED | Password for the target database connection - can be specified here or in the environment variable | |
-f | --force | REQUIRED | Required to confirm you're absolutely certain you want to do this. |
Output
There is no output from this verb.