阅读中文版本

Ephemeral Preview Environment Workflow

Spin up a per-pull-request environment so changes can be reviewed and tested in isolation and torn down automatically.

Overview

Provide isolated, automatically cleaned preview environments per change.

This workflow is reusable across teams and environments; adapt the commands to your tooling while keeping the sequence and checkpoints intact.

Environment and prerequisites

• Infrastructure as code
• A CI pipeline
• A namespace or account per preview

Procedure

1. Provision on pull request

Create an isolated environment when a pull request opens, with its own namespace.

Expected state: Each change gets an isolated environment.

2. Deploy and expose

Deploy the change and provide a stable URL for reviewers.

Expected state: Reviewers can reach the preview.

3. Test in isolation

Run automated and manual checks against the preview without affecting shared environments.

Expected state: Testing does not disturb others.

4. Tear down on merge or close

Destroy the environment automatically when the pull request ends.

Expected state: No orphaned environments accumulate.

# create a preview namespace per pull request
kubectl create ns preview-pr-4821

Verification

Confirm a pull request creates an isolated environment, provides a URL, and destroys it on close.

Decision points

Shared staging or per-change previews?

• Per-change for isolation
• Shared staging only

Recommendation: Use per-change previews for isolated testing; shared staging for integration.

Full stack or partial preview?

• Scale down but keep the shape
• Minimal stub

Recommendation: Keep the same shape at lower scale so previews are representative.

Common failures

• Shared staging conflicts between reviewers.
• No teardown accumulates orphaned environments.
• Minimal previews miss integration issues.