The Problem
Reviewing Magento code changes from a diff is insufficient for a meaningful category of changes — frontend modifications, checkout flow alterations, admin interface changes, and anything that interacts with real data shapes. Screenshots in PRs are better than nothing. A live working environment is a different category of tool.
Without per-PR environments, the review workflow is: PR opened → reviewed from diff → merged to staging → tested on shared staging → feedback → back to PR → repeat. Shared staging is a bottleneck — multiple PRs queue behind each other, and changes interfere with each other’s testing.
The Solution
On-demand ephemeral environments provisioned automatically on PR open. Each environment is a full Magento stack — web server, PHP-FPM, MySQL, Redis, Elasticsearch — seeded with anonymised production data. The environment URL and admin credentials are posted to the PR thread automatically.
Provisioning Flow
Trigger: PR opened or ready_for_review event dispatched to GitHub Actions.
Provisioning: Ansible playbook provisions the environment on a host from the CI runner pool. The full Magento stack is containerised using Warden — consistent service versions matching production exactly, including Elasticsearch version, Redis configuration, and PHP-FPM settings. Provisioning time: approximately 5 minutes from trigger to live URL.
Configuration: Store base URL, admin URL, and store-specific configuration applied automatically from the PR’s target store configuration. Admin credentials generated per environment and posted to the PR comment.
Database seeding: The environment is seeded from the latest anonymised production dump — real product catalogue, real category structure, real order history shapes, no real customer PII. This matters: tests that pass against synthetic data sometimes fail against real data shapes, particularly in category trees, product attribute configurations, and order histories.
Code: The PR branch is checked out and deployed into the environment. Static content deployed, cache warmed for the primary navigation paths.
Lifetime Management
The environment lives until the PR is merged or closed. On merge or close, a GitHub Actions cleanup job tears down the environment and removes the host from the runner pool. A confirmation comment is posted to the PR thread with the teardown timestamp.
For long-lived PRs, the environment is refreshed nightly with the latest anonymised production data dump to keep it representative.
Access
Environment URLs follow a consistent pattern: pr-{number}.{store}.staging.example.com. Engineers, QA, and invited client stakeholders access via the link in the PR. Admin access requires the per-environment credentials posted to the PR.
VPN access is required for admin panel access — production security posture maintained even on ephemeral environments.
Impact
The effect on the review process is significant. QA testers have a working environment to test against from the moment a PR is opened. Clients invited to review changes can do so on real working code without waiting for a staging deployment. Regressions that only manifest with real data shapes — a significant category — are caught before merge.
The development feedback loop for frontend changes in particular has improved substantially. Previously, a frontend PR would wait for a staging slot, be tested by QA, produce feedback, require changes, and repeat. Now the cycle happens against the PR’s own environment without queuing behind other changes.
The anonymised data pipeline also delivered a secondary benefit: developers work with realistic data locally, improving development quality outside of the PR review process.
What We Learned
The data seeding pipeline is the highest-value part of the system. Environments seeded with synthetic data miss a class of real-world bugs that only reproduce against production data shapes. Investing in the anonymisation pipeline — stripping PII while preserving data structure — paid dividends beyond ephemeral environments, becoming the standard for local development data as well.
Teardown automation is critical. Without it, runner hosts accumulate environments indefinitely and costs compound. Tying teardown to PR lifecycle events (merge, close) handles the common case; a nightly cleanup job handles orphaned environments from edge cases (force-pushed branches, API failures).