Deploying Changes

Available to: Developers, Admins Minimum plan: Free

This guide walks through the step-by-step process of creating and executing a deployment in TitanRDM. A deployment applies a branch's table definition changes to an environment — creating new tables, altering columns, or removing deleted tables in that environment. For the conceptual overview, see Deployments.

Developers deploy their own development branch directly to their private Dev environment. Deployments to shared environments such as Stage and Prod are created for you when changes are promoted (see Promoting Changes) and then deployed from the Deployments page.

New deployment page

Prerequisites

At least one table definition on your current branch with changes not yet deployed to the target environment (shown by an amber "Environment • pending" pill on the Table Definitions page)
Deployer permission on the target environment, or ownership of the private environment (or Account Administrator)

Step 1: Navigate to Deployments

Click Development > Deployments in the sidebar
Choose the environment's tab — it opens on your current environment

Each tab lists the environment's pending deployments in the order they were created, followed by its history. Each deployment shows the branch it came from, the promotion that created it (if any), its status, creator, and dates.

Step 2: Create a New Deployment

Click New Deployment
Choose the target environment — the environments your current branch deploys to are listed at the top
TitanRDM displays the table definitions with changes not yet deployed to that environment

The table list shows: - Table name — the table definition name - Domain — which domain the table belongs to - Checkbox — select which tables to include

You can filter by name or domain, and sort by name, domain, or selection status.

Selecting Tables

Select all — include every table that needs deployment
Select specific tables — check only the tables you want to deploy now

Tip: If you are making related changes across multiple tables (e.g., adding a foreign key that references a new table), include both tables in the same deployment. TitanRDM handles dependency ordering automatically.

Optionally add a description, then click Create Deployment

Step 3: Review the Diff

After creation, you are taken to the deployment detail page. The diff shows exactly what will change when you deploy:

Table-Level Changes

Badge	Meaning
New	A new table will be created
Modified	An existing table will be altered
Deleted	A table will be removed (renamed with `_t_rem` suffix)

Attribute-Level Changes

For each table, you see detailed changes:

Table attribute changes — name, database table name, domain, description, load type, lookup display column
Column changes — new columns being added, existing columns being modified, columns being removed
Column attribute changes — for each modified column: name, data type, length, scale, primary key, required, foreign key, valid values, description

Each change displays the old value and new value side by side.

Deployment diff review

Step 4: Deploy

Once you have reviewed the changes and are satisfied:

Check any warnings at the top of the page (see below)
Click Deploy
TitanRDM applies the changes to the environment
On success, the deployment status changes to Deployed, and the tables show as up to date for that environment

Warnings Before Deploying

Deployments apply the branch's table definitions as they are when you click Deploy. The deployment page warns you when:

a table has changed since the deployment was created, for example by a later promotion (which is named) — deploying now applies those changes too
older deployments to the same environment are still pending — you are asked to confirm, but are not blocked
the environment is a production environment — you are asked to confirm

If a deployment applies changes an older pending deployment was waiting for, the older one is marked Superseded.

What Happens During Deployment

For each table in the deployment:

Table State	What Happens in the Environment
New table	The table is created with all its columns
Modified table	The table is altered to match the definition
Deleted table	The table is retired (renamed, not dropped)

Tables are deployed in dependency order — if Table A references Table B via a foreign key, Table B is deployed first.

Step 5: Verify

After a successful deployment:

Make sure the environment you deployed to is your current environment
Navigate to the Tables section in the sidebar — your new or modified tables should appear under their domain
Open a table to verify the column structure in the data grid

Deployment Request Workflow

If you cannot deploy to an environment yourself:

Open the deployment
Click Send Deployment Request
Optionally add a comment explaining the changes
The environment's deployers receive an email with a link to the deployment

Deployers (members of the environment's Deployer group) can then:

Deploy — execute the deployment
Reject — mark the deployment as rejected with an optional comment

The creator or a deployer can Cancel a deployment that is no longer needed.

Handling Failures

If a deployment fails:

The status changes to Failed
The error message is displayed on the deployment detail page
The diff is preserved so you can see what was attempted

Recovery Options

Option	When to Use
Retry	Fix the underlying issue (e.g., correct a column definition) and click Retry. TitanRDM rebuilds the diff and re-executes.
Abandon	If the changes are no longer needed, click Abandon to discard the deployment. The environment's deployers are notified.

Common Failure Causes

Error	Cause	Fix
Type cast error	Changing a column type when existing data is incompatible	Correct the data first, or change the column type to something compatible
Table already exists	Attempting to create a table that already exists (stale state)	Check for orphaned tables; contact support if needed
Foreign key reference error	A referenced table does not exist yet	Include the referenced table in the same deployment

Deployment Actions (Audit Trail)

Every deployment maintains a complete audit trail:

Action	Description
Created	Deployment prepared with selected table definitions
Request Sent	Deployment request emailed to the environment's deployers (optional)
Deployed	SQL changes successfully executed
Failed	An error occurred during execution
Rejected	An approver rejected the deployment
Cancelled	The deployment was cancelled (treated as abandoned)
Abandoned	The deployment was discarded; deployers notified
Superseded	A later deployment to the environment already applied these changes

Each action records the user, timestamp, and optional comment.

Deployments List

Development > Deployments has a tab per environment. Pending deployments are listed oldest first, then the environment's history (15 per page). Click any deployment to view its detail page with the full diff and action history.

Tips

Batch related changes — include tables with interdependent changes in the same deployment
Deploy frequently — smaller, focused deployments are easier to review and debug than large batches
Review carefully — once deployed, structural changes are applied immediately; there is no automatic rollback
Test in your own environment first — deploy your development branch to your Dev environment before promoting
Deploy Stage before Prod — when a promotion creates deployments for several environments, deploy and test the non-production one first

Deployments (Concept) — lifecycle and architecture overview
Promoting Changes — moving definitions to another branch, which creates deployments
Environments — the environments you deploy to
Working with Branches — branch management
Table Definitions — what gets deployed
Creating Tables — the workflow that leads to deployment