Greentic · Next-Gen Deployment
Phase C closed, Phase D opened: the deployer grew a real control plane this week.
The week in one paragraph. Greentic's deployment state — the record of which environments exist, which bundles and revisions run where, and how traffic is split — has always lived in files on one machine, edited directly by the gtc op CLI. This week we finished the configuration pipeline (Phase C), then started turning that file-based state into a proper client–server system (Phase D): the CLI now speaks a typed, network-ready protocol, and the first version of a central store server exists, backed by SQLite and hardened against the classic failure modes. This is the foundation for running Greentic on Kubernetes.
Setup answers now flow cleanly from wizard to runtime, with secrets kept out of plain files.
The last Phase C pieces landed Monday–Tuesday: setup wizards write a typed pack-config-input.v1 file, the deployer turns it into a per-revision pack-config.v1 at stage time, and the runtime picks it up — with secret values stored as references, never as plaintext in config artifacts. A QA-spec seam was added so environment wizards can be rendered by frontends later.
deployer #253–#256 · start #240–#242 · operator #92 · bundle #127 · setup #135
Before building new deployers, we built the test that judges them — and picked the simplest database that works.
deployer #257, #258
You can't send a code closure over a network — so every state edit became a named, typed operation.
Previously, 33 places in the CLI edited environment files directly inside little code blocks run under a file lock. That works locally but can never work remotely. We decomposed all of them into 15 groups of typed operations — "create environment", "stage revision", "set traffic split", "add bundle", "rotate webhook secret", and so on — behind a single EnvironmentMutations interface. This landed as 15 small PRs in one day, with the full test suite green between each one, so nothing ever sat half-migrated.
deployer #259–#274 (trait shell + verb-group train)
The same CLI now works against local files or a remote server — and the server's first slice exists.
HttpEnvironmentStore speaks the A8 wire contract: optimistic concurrency (every write pins the exact version it expects — two operators can't silently overwrite each other), idempotency keys (a retried request replays the original result instead of applying twice), and an audit record on every change.gtc op picks local files or remote HTTP at startup via --store-url / GREENTIC_STORE_URL — no separate binary, no behavior fork.greentic-operator-store-server: SQLite storage with versioned, integrity-checked rows, health/readiness endpoints, and a clean storage interface so other backends can plug in later. Its 20 tests run as plain cargo test — the old Postgres tests needed Docker and were skipped in CI; these run every time.deployer #275 (client), #276 (switch), #278 (server scaffold)
Two adversarial review rounds tried to break the new code. Every confirmed finding was fixed the same day.
deployer #277 (client fidelity) + hardening commits on #278
Describe an environment declaratively; the CLI makes reality match.
New gtc op env apply reads a single env-manifest.v1 file — environment, bundles, endpoints, secrets — and converges the live state to it, instead of operators issuing a dozen imperative commands. gtc doctor gained env-readiness checks (trust root, endpoint linkage, secret references), and --check turns the manifest into a CI gate that fails when reality has drifted.
deployer #279, #280, #282 · start #247