SQL Deploy

1.1 · 2026-09-29

A desktop application over the same engine as the command line: the plan as a tree with a diff per object, environments that say what may happen where, reference data deployed as the rows that differ, and a blank server taken to a deployed one in one press.

• A desktop application. SqlDeployGui reads the same manifests and environment files, shows the plan as steps and objects with a diff of each change, writes and runs the same script, and shows the server's output as it arrives. Nothing it does is unavailable from the command line; what it adds is seeing the plan before running it, and watching it run.

• Environments say what may happen there. allow: [upgrade, create, drop] and guiMode: ask | approved | disabled belong to the environment file, so a production environment can be compared and its script copied, but never deployed by clicking. Everyone can have an environment of their own under local/, written from the repository's template and never committed.

• Create and deploy. A manifest declares the databases its environment consists of and how to create them; the application creates what is missing, compares against what it has just built, runs the postCreate steps and deploys — one press from a blank server. sqldeploy create does the same from the command line.

• Reference data as files. A data step holds rows as CSV or SQL and deploys the rows that differ, in seed, update, merge or replace mode, per table; a seed into a table the same run creates deploys with it.

• Choose what goes into a run. Every step and every object has a tick; an unticked object leaves the script, and the script's header says so. Ticks are remembered per manifest and per environment. A step follows the database it deploys to, and a step whose database is not part of the run is not compared at all.

• Best effort and step through, chosen per deployment when it is confirmed: one object at a time, retried in passes, for a set of procedures whose order is wrong; or one step per transaction, pausing between them, for bringing a database up a step at a time. A step the schema model cannot hold entirely is deployed for what it can, and the rest is reported.

• Steps are compared in parallel and the plan fills in as they finish; the environment can be changed, and a comparison stopped, while one is running. A server that does not answer never traps the window.

• A deployment never lands in whatever database the login opens. A step names its database or inherits the target's, and one with neither fails by name. An explicitly empty password is accepted; an unset one is not.

• The script says more while it runs. Messages are delivered as they happen rather than at the end of the batch; a running batch can be cancelled at once and its transaction rolled back; a table rebuild's own DROP TABLE no longer counts as data loss.

• Source files are read in the encoding they were saved in, and a manifest can name the root its paths resolve against, so a manifest in deploy/ reads the repository's layout.