Ephemeral PR Preview Environment Platform (AKS-based)

From local to cloud-accessible environments

Running on kind requires manually loading Docker images, managing port forwarding, and sharing access via screen sharing. A preview environment on AKS is publicly accessible over HTTPS with a real TLS certificate — anyone with the URL can review a feature branch from any device, anywhere.

GitOps-style PR preview environments

Each branch maps deterministically to a running environment — feature/my-branch becomes namespace feature-my-branch at https://feature-my-branch.IP.nip.io. The cluster state always reflects the Git state. There is no shared staging server accumulating unknown changes, and no manual environment management.

Path-based change detection

The build pipeline diffs the branch against main and builds only the service that actually changed. A CSS fix in the frontend does not trigger a backend build. This reduces build times and Docker Hub push volume significantly compared to rebuilding everything on every push.

Smart image tag resolution

When only one service changes on a new branch, the other service's branch-specific image tag doesn't exist yet. Rather than failing, the deploy pipeline checks Docker Hub and falls back to main-latest for the unchanged service. The environment is always deployable from the first push on any new branch.

Forced rolling restarts on every deploy

A deploymentId annotation on pod templates is set to the pipeline build ID on every deploy. When Helm sees this value change it updates the pod spec, triggering a rolling restart — preventing stale pods when only image content changes without a tag change.

Pipeline trigger chaining across repositories

The deploy pipeline in the Kubernetes repository triggers automatically on completion of the build pipeline in the application repository using Azure DevOps pipeline resource triggers. The repositories are fully decoupled — neither needs to know the other's internals — but the full build-to-deploy flow is automatic.

Idempotent bootstrap

The bootstrap pipeline checks whether each component is already installed before acting, making it safe to rerun at any point. It serves as both the initial setup script and the recovery script. Recreating the entire cluster from scratch requires a single manual pipeline run with no command-line interaction.

Automated TLS for every environment

cert-manager watches for new ingress resources and automatically provisions a Let's Encrypt certificate for each one within minutes of namespace creation. There is no certificate management in the pipeline — HTTPS works out of the box for every preview environment.

Cost-aware scheduling as code

The cluster start/stop schedule is version-controlled pipeline YAML, not a manually configured Azure job. It can be reviewed, modified via PR, and rolled back like any other change. The schedule is self-documenting — the cron expressions and their intent are visible to anyone reading the repository.

Namespace isolation as a security boundary

Each environment runs in its own Kubernetes namespace with its own secrets, configmaps, and persistent volumes. A crash or misconfiguration in one environment cannot affect another. Environments are deleted cleanly with a single namespace deletion — all associated resources are removed automatically.