Lifecycle Management: The Automation Loop

Tying Infrastructure to Git Events

The magic of ephemeral environments is that their entire lifecycle — creation, update, and destruction — is driven by Git events. Your CI/CD pipeline subscribes to webhooks from your Git provider (GitHub, GitLab, Bitbucket) and reacts accordingly. No human manually provisions or tears down anything.

Here is the complete lifecycle:

1. Creation (PR Opened)

When a developer opens a new PR:

1. The pipeline builds a Docker image tagged with the specific commit SHA (e.g., myapp:abc1234).
2. It creates a unique, isolated Kubernetes Namespace (e.g., pr-123). A namespace is a logical partition inside a Kubernetes cluster — resources in pr-123 cannot interfere with resources in pr-124.
3. It deploys the application into that namespace using a templating tool like Helm or Kustomize, substituting in the PR-specific image tag and hostname.
4. It configures a dynamic Ingress rule — a routing rule that tells the cluster's load balancer to forward traffic from pr-123.my-domain.com to the pods in the pr-123 namespace.
5. A bot comments on the PR with the live URL, so reviewers can access it with one click.

2. Update (New Commit Pushed to the PR)

When the developer pushes a new commit to the same branch:

1. The pipeline builds a new Docker image with the new commit SHA.
2. It runs a helm upgrade (or equivalent), which performs a rolling update of the pods in the existing namespace. The URL stays the same; the code underneath it changes.

3. Destruction (PR Closed or Merged)

This is the most important step. If you forget this, environments accumulate indefinitely and costs spiral out of control.

1. The pipeline detects the pull_request: closed event.
2. It runs kubectl delete namespace pr-123, which instantly wipes out every resource in that namespace: Pods, Services, ConfigMaps, Secrets, PersistentVolumeClaims, and Ingress rules.
3. The DNS entry for pr-123.my-domain.com is removed (either automatically via ExternalDNS or via a cleanup script).

The Ingress Routing Pattern

The Ingress configuration is what makes the environment accessible from a browser. A wildcard DNS record (*.preview.example.com → cluster load balancer IP) combined with a wildcard TLS certificate means you can create arbitrarily many subdomains without touching DNS for each one. The Ingress controller (typically NGINX or Traefik) reads the Host header on incoming requests and routes to the correct namespace. The Ingress resource created per PR names its host, references a TLS secret managed by cert-manager, and routes all paths to the app's Service within that PR's namespace.