Skip to main content
SnowOps Labs
All of the catalog
Scenario

Multi-Env Promotion (Dev → Staging → Prod)

Run a real release pipeline by hand: build versioned go-api images, deploy one to dev, and promote it forward to staging then prod with plain kubectl. Promotion here is a genuine image rollout (new ReplicaSet), not a ConfigMap edit — you build vNEXT, roll it out per environment, and watch each env's /version change as the release moves down the pipeline.

DeliveryVerifiedk3dkind
Definition on GitHub

What you'll do

  • Understand environment separation as Kubernetes namespace isolation (env-dev / env-staging / env-prod)
  • Build multiple immutable, versioned images (go-api:v1.0.0, v1.1.0, …) and load them into the cluster
  • Deploy a new version to dev only, and prove the other environments are unchanged
  • Promote a version dev → staging → prod with 'kubectl set image' + 'kubectl rollout status' — a real rollout
  • Roll back a bad promotion with 'kubectl rollout undo'
  • Verify the pipeline: every environment's running image matches its declared tag

Stages

  1. 1seed-baseline

    Build the go-api:v1.0.0 baseline image and load it into the cluster

    baseline-image
  2. 2dev-env

    Deploy go-api:v1.0.0 into the dev environment (namespace env-dev)

    dev-environment
  3. 3staging-env

    Deploy go-api:v1.0.0 into the staging environment (namespace env-staging)

    staging-environment
  4. 4prod-env

    Deploy go-api:v1.0.0 into the prod environment (namespace env-prod)

    prod-environment

Prerequisites

These are installed into the lab cluster for you — listed so you know what the scenario actually depends on.

ingressgo-api

Related scenarios

The incident field notes

One real Kubernetes failure a week — the symptom, the commands that found it, and the fix. Written from actual lab runs, not from memory.

You'll get the Kubernetes Incident Response Field Guide, plus occasional emails about new scenarios, posts and paid offerings such as courses and workshops. Unsubscribe any time.