Turn a pull request into a real review environment.

Case file / GitOps preview environments

A GitOps control plane turns pull-request intent into a single-service preview or coordinated UAT stack, then records the revision and removes the environment through the same workflow.

Hand-drawn GitOps workflow from pull request to single-service and full-stack preview environments

Project snapshot

Client
SaaS platform
Architecture
Microservice application stack
Cloud
AWS and Kubernetes
Control plane
GitHub labels and an automation repository
Delivery
Argo CD ApplicationSets and Helm
Modes
Single-service preview and coordinated full-stack UAT

A review workflow built around the way developers already work.

01

Problem

Cross-repository changes needed real review environments without repeated platform setup.

02

Approach

Labels and an automation repository declare intent; GitHub Actions and Argo CD reconcile it.

03

Outcome

One Git workflow now creates single-service previews, full-stack UAT, revision evidence, and teardown.

Two trigger modes

Match environment scope to the change under review.

Label / preview

Single-service preview

A pull request and shared token deploy one service. Other repositories can join the same environment when needed.

  • Right-sized for one repository
  • Supports ad-hoc multi-repository joins
  • Removing the label removes that application

Label / fullstack-preview

Coordinated full-stack UAT

A YAML declaration names the environment and repositories. The reconciler coordinates pull requests and deploys the stack together.

  • Designed for cross-service work
  • Supports per-repository branch overrides
  • Deleting the declaration tears down the generated set

Architecture note

One control path from preview intent to a live Kubernetes environment.

GitHub records intent, the automation repository coordinates cross-repository state, and Argo CD reconciles runtime, DNS, and data.

Desired state to running evidence

Git remains the control surface from creation through cleanup.

Branch, commit, and image retained
01

Developer intent

Single servicePR + preview label
or
Full-stack UATYAML environment declaration
02

GitOps control plane

Automation repositoryIdempotent reconciliation
Argo CD ApplicationSetsPR metadata to Helm values
03

Ephemeral environment

Kubernetes namespaceThe preview token defines the environment boundary
WebAPIWorkers
MySQL snapshotRedis
Review URLDNS, ingress, certificate, and deployed revision
Running status and deployed revision return to the pull request.
Cleanup follows the same path.Remove the label, close the pull request, delete the declaration, or let policy expire the environment.
Control flowObserved or reconciled stateCleanup trigger
A pull-request label or a full-stack YAML declaration flows through an automation repository and Argo CD into an isolated Kubernetes environment. Runtime status returns to the pull request, and removal follows the same reconciled control path.

AI-assisted validation

A safe validation surface for AI-prepared changes.

The preview exposes the revision, health, tests, logs, configuration differences, and cleanup status an engineer needs before approval.

Deployed revision
Health and tests
Logs and configuration differences
Cleanup status

Lifecycle and cleanup

The same automation creates, updates, and removes the environment.

  1. 01

    Create

    A label or YAML file records the environment in Git.

  2. 02

    Reconcile

    Automation updates pull requests and Argo CD applications.

  3. 03

    Review

    A predictable URL exposes the running revision for review.

  4. 04

    Remove

    Closing or deleting the Git intent triggers cleanup.

Delivered pattern

What the engagement established.

  • Pull-request labels act as the developer control surface.
  • An automation repository declares full-stack environments and branch overrides.
  • ApplicationSets turn branch and commit metadata into Helm applications.
  • Each environment receives runtime, DNS, data, and cache dependencies.
  • Git state drives updates and cleanup.

Adaptation checklist

What each client must decide.

  • Reviewer access, secret storage, and production-data boundaries.
  • Masking, synthetic data, retention, and snapshot policy.
  • Readiness, database restore, DNS, and certificate timing.
  • Quotas, expiry rules, and cost ownership.
  • Alerts for stuck or orphaned resources.

Results

Reviewable environments without a parallel release process.

  • Cross-service validation happens before merge.
  • Environment scope matches the change under review.
  • Routine creation no longer needs direct cluster work.
  • Every environment stays tied to branch, commit, and image context.
  • Creation, updates, and teardown follow one control path.

After handover

The preview control plane stays inside your accounts and repositories.

Your team keeps the workflows, ApplicationSets, Helm configuration, cleanup rules, review URLs, and operating context.

Schedule a platform call