Deployments
Available to: Developers, Admins Minimum plan: Free
A deployment takes the table definitions of a branch and applies them to an environment — creating new tables or altering existing ones in that environment. Until you deploy, changes to table definitions are metadata only and do not affect any environment's tables.
Every deployment targets one environment and comes from the branch that deploys to it. Deployments are created in two ways:
- By a promotion. When changes are promoted into a branch, a deployment is created for each environment that branch deploys to — for example Stage and Prod for
main. The deployment links back to the promotion that created it. - Directly by a developer. Developers deploy their own development branch straight to their private Dev environment to test changes. Administrators can also create a deployment to bring a shared environment up to date, for example after adding a new environment.
Why Deploy?
TitanRDM deliberately separates defining a table from creating it. This gives you a review step between making a change and applying it:
- You can add, rename, or remove columns on a table definition without any risk to live data
- You can review exactly what will change before it takes effect
- Multiple table changes can be batched into a single deployment
- If something goes wrong, the deployment fails cleanly without leaving the database in a partial state
The Deployment Lifecycle
A deployment moves through these statuses:
Created → Deployed
├── Failed → (Retry)
├── Rejected
├── Abandoned
└── Superseded
| Status | Meaning |
|---|---|
| Created | The deployment has been prepared and is ready for review. No changes have been applied yet. |
| Deployed | All changes were successfully applied to the database. |
| Failed | One or more changes could not be applied. The deployment can be retried. |
| Rejected | An approver reviewed the deployment and rejected it. |
| Abandoned | The deployment was cancelled without being applied. |
| Superseded | Nothing was left to deploy: another deployment to the same environment had already applied these changes. |
The Deployments Page
Development > Deployments has a tab for each environment you can access. Each tab lists:
- Pending deployments, in the order they were created (oldest first) — the order you would normally deploy them in
- History — deployments that have been deployed, rejected, abandoned or superseded
Each deployment shows the branch it came from and, if it was created by a promotion, a link to that promotion and its pull request. A deployment made by your CI/CD pipeline also shows the Release that deployed it.
Creating a Deployment
- Navigate to Development > Deployments and click New Deployment (or, on a development branch, select tables on the Table Definitions page and click Deploy)
- Choose the target environment from the environments your current branch deploys to
- TitanRDM lists the table definitions with changes not yet deployed to that environment
- Select the tables you want to include in this deployment
- Review the changes
The Diff Review
Before deploying, TitanRDM shows you a detailed diff of every change that will be applied. The diff is organised into four levels:
| Diff Level | What It Shows |
|---|---|
| Table changes | New tables being created, existing tables being updated |
| Table attribute changes | Changes to table-level properties: name, database table name, domain, description, load type, lookup display column |
| Column changes | New columns being added, existing columns being updated, or columns being removed |
| Column attribute changes | Changes to column-level properties: name, data type, primary key, foreign key, length, scale |
Each change shows the old value and new value side by side, so you can verify exactly what will happen.
Deploying
Once you have reviewed the changes:
- Click Deploy
- TitanRDM applies the changes to the environment
Deploying requires the Deployer permission on the environment. Developers can always deploy to their own private environment.
Before You Deploy
A deployment applies the branch's table definitions as they are when you click Deploy. The deployment page warns you when:
- A table changed after the deployment was created — for example because a later promotion changed it. The warning names the promotion. Deploying now applies those later changes too.
- Older deployments to the same environment are still pending. Deployments are normally applied in the order they were created. TitanRDM asks you to confirm, but does not block you.
- The environment is a production environment. You are asked to confirm before deploying.
When a deployment applies changes that an older pending deployment was waiting to apply, the older deployment is marked Superseded.
What Happens During Deployment
For each table in the deployment, TitanRDM creates the table in the environment (for new tables) or alters it to match the definition (for changed tables). Each environment has its own copy of the table and its data, so deploying to Stage does not change Prod.
Dependency Ordering
TitanRDM automatically orders table changes based on foreign key dependencies. If Table A references Table B via a foreign key, Table B is deployed first. This prevents errors from referencing tables that do not yet exist.
Deployment Actions
Every deployment records an audit trail of actions:
| Action | When |
|---|---|
| Created | When the deployment is first prepared |
| Started | When the deploy button is clicked |
| Deployed | When all changes are successfully applied |
| Failed | If an error occurs during deployment |
| Rejected | If an approver rejects the deployment |
| Abandoned | If the deployment is cancelled |
These actions include timestamps and the user who performed them, providing a complete audit trail.
Handling Failures
If a deployment fails:
- The error message is displayed on the deployment detail page
- The deployment status changes to Failed
- You can fix the underlying issue (e.g., correct a column definition) and click Retry
- Or you can Abandon the deployment and create a new one
Common failure causes:
- A column type change that is incompatible with existing data (e.g., changing varchar to integer when non-numeric data exists)
- A foreign key reference to a table that has not been deployed yet
- A naming conflict with an existing database object
Deployment vs Promotion
It is important to understand the distinction:
| Deployment | Promotion | |
|---|---|---|
| What it does | Applies a branch's table definitions to an environment | Copies table definitions from one branch to another |
| When to use | To create or update tables in an environment | When changes on your branch are ready to move into a shared branch |
| Scope | One branch → one environment | Between two branches (source → target) |
A typical workflow:
1. Create a new table on your development branch, or clone an existing table from main
2. Make your changes
3. Deploy to your Dev environment and test
4. Promote from your branch to main — deployments are created for Stage and Prod
5. Deploy to Stage and test
6. Deploy to Prod
Deleting Tables
TitanRDM provides a safe removal process for table definitions on the table definitions index page. When you remove a table, the physical database table is renamed (not dropped). See the Removing a Table page for more details.
Related Pages
- Promoting Changes — moving definitions between branches
- Table Definitions — what gets deployed
- Environments — the environments you deploy to
- Branches — where table definitions are developed
- Your First Table — includes a deployment walkthrough
- Removing a Table — safe table removal process
- Branch Cloning — pulling existing table definitions from a higher environment branch