Managing Releases & Execution
A release is a versioned, environment-scoped aggregate of Release-type scripts, deployed as one fail-fast, dependency-ordered unit. This page covers the release state machine, per-script target binding, execution modes, catalog-driven target discovery, the execution record, deterministic rollback generation, and multi-environment promotion.
Execution Modes
The Execute dialog exposes an Execution mode governing multi-statement failure behavior. All modes run on a single connection, so session state (temp tables, SET) carries across statements, and the record captures per-statement outcome.
- Transactional (all-or-nothing), one enclosing transaction; first failure rolls back the whole script, leaving the target untouched. Default. Non-transactional statements (
CREATE INDEX CONCURRENTLY,VACUUM) must use "Stop on first error". - Stop on first error, sequential, halt on first failure; already-applied statements persist (no rollback).
- Continue on error, attempt every statement, report exactly which failed. For idempotent batch remediation.
Composing a Release
Create with name, version (semver or any convention), description, and target environment; it opens in Draft. Add scripts from a filterable picker (name / tag / type / approval status). Membership rules:
- Only Release-type scripts are eligible (not Ad-hoc).
- Membership is mutable only in Draft.
- The gate to Ready requires every member Approved.
- Execution order is the dependency topology, not insertion order.
Release State Machine
| Status | Meaning | Allowed transitions |
|---|---|---|
| Draft | Assembling; membership mutable. | Add/remove scripts, edit, advance to Planning |
| Planning | Membership frozen; driving remaining approvals. | Request approvals; advance to Ready iff all Approved |
| Ready | Fully approved; deployable. | Deploy to target environment |
| Deploying | Executing against targets. | Read-only progress |
| Completed | All scripts succeeded. | Review results; promote to next environment |
| Failed | A script failed; frontier halted. | Inspect error; fix & retry; or roll back |
| Rolled Back | Manually rolled back post-failure. | View history |
Deploying a Release
From a Ready (or signed_off) release, open Execute Release, review per-script target assignments, supply a fallback connection for any unbound script, and execute. The engine then, per script in dependency order: connects to the script's bound target (or the fallback, with optional database override), dispatches the statements through the dialect driver, records RUNNING → COMPLETED | FAILED, and on any failure halts immediately, remaining scripts are marked not-attempted. A live progress panel tracks each script as it runs, pending, running (spinner), completed, failed, or skipped, with rows-affected and timing, updating in place as the release advances, mirroring single-script execution. Each result (status, error, timing) renders inline.
Per-Script Target Binding
Each script persists its own target_connection_id and target_database, so a single release can fan out across instances and dialects, one script mutating a PostgreSQL schema while another updates a MongoDB collection, in the same coordinated deploy. Binding is resolved at execution time.
Standalone Execution
Execute a single script directly: the Execute modal shows its content, a type-filtered instance picker, and a catalog-introspected database picker. Running dispatches via POST /api/db-devops/executions/run and streams the result inline (RUNNING → COMPLETED | FAILED with message).
Target Discovery
Target pickers enumerate live databases per instance via GET /api/db-devops/connections/:id/databases:
| Engine | Source | Filtering / detail |
|---|---|---|
| PostgreSQL | pg_database | Excludes template0/template1; includes size. |
| MySQL / MariaDB | information_schema.schemata | Excludes information_schema, mysql, performance_schema, sys. |
| SQL Server | sys.databases | ONLINE only; size from sys.master_files. |
| MongoDB | admin.listDatabases() | All DBs with sizeOnDisk. |
| Oracle | v$pdbs | Pluggable DBs; falls back to dba_data_files for non-CDB. |
Execution Record
Each run persists an immutable record:
| Field | Content |
|---|---|
| Script Name | Executed script. |
| SQL Snapshot | Exact bytes sent, captured at execution time. |
| Target Connection | Resolved connection (+ database override). |
| Executed By | Triggering actor. |
| Start / End / Duration | Timing. |
| Status | RUNNING, COMPLETED, FAILED, ROLLED_BACK. |
| Rows Affected | For DML. |
| Error Message | Full driver error on failure. |
Deterministic Rollback Generation
On PostgreSQL targets, before the forward script runs the engine captures the relevant pre-change state and derives an exact inverse, not a guess, but a rollback computed from the actual prior state, saved on the script and shown in the result:
- UPDATE → per-row restores of prior values, matched by primary key.
- DELETE → INSERTs re-creating removed rows.
- CREATE (table/index/view/sequence/function/procedure) → DROP of that object.
- ALTER / CREATE OR REPLACE (function/procedure/view) → restore of the prior definition.
- ADD COLUMN → DROP COLUMN; RENAME → inverse rename.
Genuinely irreversible operations, TRUNCATE, DROP, DROP COLUMN, lossy type changes, are enumerated as irreversible rather than fabricated, so the rollback's coverage is explicit.
Failure Handling
On failure during deploy: the driver error is recorded in full, the frontier halts (no further scripts attempted), and the release moves to Failed. Recovery paths: fix the script's SQL (resets to Draft, re-approval required), retry unchanged if the cause was environmental, or roll back manually and mark Rolled Back.
Multi-Environment Promotion
Development -> QA -> Staging -> ProductionPromotion redeploys the same release, identical scripts, versions, and hashes, to the next environment's connections, with optional approval gates between stages. No inter-stage edits: what was validated below is bit-identical to what reaches production.