CI and deployment with fixtures
The last tutorial page takes the project you’ve been working on and runs it somewhere else — first in a CI-style job, then from a second directory with its own database. Both are things you can actually do today. Real deployment is not, and this page is explicit about where the line is.
Run the type check and the tests in a clean copy of the project, with the same prepared identity and connector data you used locally.
A job that passes has to include the workflow test output and show that it ran against real PostgreSQL. A type check alone proves the code compiles — it does not prove a workflow ran. Those get confused often enough to be worth stating.
Save four things together: the commit, the exact dependency versions that got resolved, the database image, and the test output. Apart, they don’t prove much; together, they let someone reproduce your run.
For this workshop, “release” means one thing: the tested revision and its exact package versions travel together to the next machine. That’s it.
It does not mean the packages are published anywhere, and there is no release service to call.
Gate G10 — required implementation. Stay on the local path. A registry, signing, or promoting a build to somewhere else are all things that need to be built and approved first. Don’t demonstrate them as if they existed.
Copy the tested project to a second directory on the same machine, with its own configuration and its own PostgreSQL state. Start it, run the same checks, and compare the state and output with the first one.
What this proves: the project starts somewhere other than where you built it, and produces the same, explainable result. What it does not prove: anything about staging, production, or delivery over a network.
Read the bundle hashes in that comparison as “same source and same installed dependency layout”. The compiled bundle names every dependency by where the package manager put it, so the hash also moves when the layout does — a different package manager, a different pnpm major, a package installed from a tarball rather than the registry, or a changed peer set. Two targets installed from one lockfile with one pnpm agree, which is why the exercise works. Matching hashes prove the two targets run the same program; differing hashes are a question, not yet an answer.
One more thing this exercise will not show you, because a second target starts
with an empty database: a deployed Workflow Definition is immutable. Change a
definition without raising its version and the write is refused, the stored
bundle keeps running, and the deployment otherwise looks healthy. The Starter
stops on that with IFLOW_DEFINITION_NOT_REDEPLOYED; a deployment of your own
has to notice it for itself.
Gate G12 — same-machine target. If you can’t keep the second copy properly separate — separate config, separate database — stop and record it as a failure. A screenshot or a command you were going to run is not a result.
Next: Deployment for where the boundary sits, and Commands and verification for the list of what to record.