Docker and CI workflows
Repeatable local builds, artifact checks, dependency caching, and CI gates that keep deployment boring.
Takeaway
CI should prove the same thing a careful local release proves: dependencies install cleanly, checks pass, and the generated artifact matches the intended route surface.
01
Pin the boring pieces
Use the same package manager version, Node version, lockfile policy, and build command locally and in CI. Small mismatches create confusing failures that look like application bugs.
A reliable workflow should make the local release path and CI path feel nearly identical. Differences should be intentional and documented.
- Pin the package manager and Node version in project docs or CI config.
- Use frozen lockfile installs in CI.
- Run the same lint, test, build, and smoke commands locally before release.
02
Cache dependencies carefully
Dependency caching should speed up repeat builds without hiding lockfile drift. Treat cache misses as normal and keep the frozen install as the source of truth.
When cache behavior is unclear, CI failures become noisy. A good setup speeds up the common path but still fails when dependencies and the lockfile disagree.
- Cache package-manager stores, not generated application output.
- Invalidate dependency caches when the lockfile changes.
- Avoid relying on a warm cache for correctness.
03
Inspect the artifact
After build, check route output, metadata routes, and any generated assets. A green compile is not enough if an expected guide page or API endpoint is missing from the final app.
For small static-first apps, the artifact is the product. Treat the route list and smoke result as release evidence, not incidental logs.
- Confirm content routes generated from data arrays are present.
- Check API routes still return expected JSON shapes.
- Keep smoke checks focused on public behavior rather than implementation internals.