The fourteen-phase deployment.
Most converters deploy in catalog order and fail on the first dependency loop. Trekport resolves dependencies up front and deploys in this exact sequence. Each phase is retryable. Each phase emits a typed report.
Phase sequence
| # | Phase | What it does |
|---|---|---|
01 | Pre-flight | Validate connectivity, version skew, and target capacity. Surface blocking issues before any DDL runs. |
02 | Compatibility extensions | Install the compatibility layer so every downstream conversion can rely on it. |
03 | Schemas and roles | Materialize the namespace and identity surface. Grants apply later in dependency order. |
04 | Types | Domain, composite, and collection types deploy before tables that reference them. |
05 | Sequences | Sequences land before tables so identity columns wire correctly on first deploy. |
06 | Tables | Tables deploy without foreign keys. FKs attach in the final phase to avoid circular dependencies. |
07 | Indexes | All non-constraint indexes, including functional, partial, and trigram indexes. |
08 | Standalone functions and procedures | Functions and procedures with no package wrapper. Resolved in call-graph order. |
09 | Packages | Package spec and body translated to schema-plus-functions. Cross-package references resolve through the dependency graph. |
10 | Triggers | Row-level, statement-level, INSTEAD OF, and compound triggers. After every referenced object exists. |
11 | Views and materialized views | Multi-pass deploy for view-on-view chains. Refresh strategies preserved. |
12 | Synonyms | Public synonyms reconciled to PostgreSQL search paths. Private synonyms emitted as views where applicable. |
13 | Grants and role memberships | Object grants, column grants, and role memberships in dependency order. Cascade-aware to avoid noise. |
14 | Foreign keys and validation | Constraints applied last. Row counts, checksums, and sample-row equivalence checked. Failure here aborts cutover. |
Retry semantics
Phases are independently retryable. A failed phase can be re-run after the underlying issue is resolved. The orchestrator detects already-deployed objects and skips them without manual cleanup. Idempotent phase semantics are part of the contract, not a future feature.
- Within a phase, dependent objects retry across passes until the phase converges or exceeds the configured pass limit.
- Transient connection errors are retried with exponential backoff before being surfaced. Only transient classes are retried at this layer; classified failures route to the classifier.
- On clean re-run against an already-deployed target the report shows zero changes.
Per-phase reports
Each phase emits a typed status into the deployment report. Reviewers can audit the run object by object without leaving the report.
| Field | Meaning |
|---|---|
attempted | Total objects the phase tried to deploy. |
deployed | Objects that landed cleanly on the target. |
retried | Objects that failed at least one pass before succeeding. |
deferred | Objects deferred to a later phase by the dependency resolver. |
classified | Failures bucketed by the classifier (converter / catalog / extension / out-of-scope). |
Skipping phases
The CLI accepts --phases with a comma-separated phase list for partial deploys against staging environments. The full sequence is the supported path to production.