flagon-io/g1t

public

Deploying: a migration keeps the live code right, because it runs a minute before the new code

Migrations apply before any stage, so the old code reads the new schema for a minute or more. billing/0039 rewrote comped accounts as custom terms at 100%, and for about 40 seconds the old billing code saw flagon-io as a free workspace and refused its workflows (run #55). The guide now says: add, never change meaning; change meaning in two deploys; never drop what the live code reads.

syntaqxcommitted 13h agoParent5f8154bBrowse files

1 file+18−00/1 viewed

+18−0View BlameViewed

152	152		6. Prints a table: unit, stage, result, version id, time. Each unit's full
153	153		output is kept in `$TMPDIR/g1t-deploy/<unit>.log`.
154	154
	155	+	#### Migrations run while the old code is still live
	156	+
	157	+	Migrations apply before any code, and a stage takes a minute or more, so
	158	+	for that long the code in production is the old code reading the new
	159	+	schema. A migration must keep the old code right:
	160	+
	161	+	- Add, never change meaning. New tables and columns (with defaults) are
	162	+	safe. Rewriting what existing rows mean is not: on 2026-10-08,
	163	+	`billing/0039` turned comped accounts into `custom` terms at 100%, and
	164	+	for about 40 seconds the old billing code, which knew only `comped`, saw
	165	+	flagon-io as a free workspace and refused its workflows.
	166	+	- Change meaning in two deploys. First ship code that reads both the old
	167	+	and the new form (and keeps writing the old one); then, in a later
	168	+	deploy, the migration that rewrites the rows; then, if you like, code
	169	+	that drops the old form.
	170	+	- Never drop or rename a column or table the live code reads in the same
	171	+	deploy that stops reading it.
	172	+
155	173		#### Telling the status page about a deploy
156	174
157	175		Restarts during a deploy can make a part slow for a minute, which the