ddtcorex

14 Sept 2026 ยท 2 min read

Parallel Govard environments for every branch

Running isolated Govard environments per feature branch so reviewers test real code, not descriptions

Part 2 of the Govard deep-dive series โ€” isolated environments per branch so reviewers test real code, not descriptions.

Why one shared local environment causes conflicts

A single shared local environment is a bottleneck the moment two people need it at once. Reviewer A is checking a checkout fix on feature/csp while Reviewer B needs the same machine to validate a search tweak on feature/search. Whoever wins the machine validates their own change; the other waits, or worse, both work on the same database and overwrite each other's fixtures.

The fix is isolation, not scheduling. Govard's worktree model means each branch gets its own checkout and its own container set, addressable on its own .test domain. A reviewer clicks a URL and sees the actual code on that branch โ€” no "trust me, it works" handoff, no reconstructed steps in a bug report. The environment becomes part of the pull request, not a separate favor someone has to do.

Spinning up an environment per branch

Start from a clean worktree for the branch, then bring its stack up. Because each environment is isolated, the domain and data are unique to that branch:

git worktree add ../example-store-feature-csp -b feature/csp
cd ../example-store-feature-csp
govard env up
# reachable at https://example-store-feature-csp.test

For pull-request previews, the same pattern runs in CI: a runner creates the worktree, runs govard env up, and exposes the .test URL to the reviewer. The base branch is never touched, so a failing preview never destabilizes local daily work.

Switching between environments is just a matter of which one is running. List them, bring one down, bring another up:

govard env ps --all        # list every Govard environment on the host
govard env down            # stop the current worktree's stack
govard env up              # start another branch's stack

When the branch is merged or discarded, tear the environment down so its volumes and ports are released:

govard env down --volumes  # remove containers AND their data volumes
git worktree remove ../example-store-feature-csp

Pitfalls

  • Volume or port collisions. Two environments that are not properly isolated can fight over a port or mount the same database volume. Always scope each env to its own worktree and verify with govard env ps --all.
  • Forgetting cleanup. Preview environments pile up after a busy sprint; a weekly sweep of stopped worktrees keeps disk and port ranges free.
  • Database drift between environments. If two branches were seeded from the same remote at different times, their data diverges. Re-sync from a known remote before comparing behavior, rather than assuming parity.

Next in this series: Debugging inside Govard: Xdebug, logs, and introspection โ€” /blog/govard-debugging-tooling

magento2govardworkflow