8.4 Environments — dev, staging, production
| Environment | Purpose | Typical data |
|---|---|---|
| Dev | Developer laptop or shared playground | Fake / disposable |
| Staging | Production-like rehearsal | Anonymised or synthetic; never real customer secrets if avoidable |
| Production | Real users (even if your "users" are lab testers later) | Real config with proper secret storage |
Rules of thumb:
- Config differs (URLs, feature flags) — code should be the same artifact.
- Staging should catch migration and integration surprises before production.
- Production deploys need a rollback story (previous image tag, feature flag off).
You already know how to place a VM and Security Groups from the AWS Cloud course. This chapter does not re-teach VPC, DNS or EC2 launch — only how environments fit the pipeline story.
Steps — name your environments on paper
- Draw three boxes: Dev, Staging, Prod.
- Under each, write: who can deploy, what data lives there, what URL or host nickname you would use in a lab.
- Write one sentence: "We promote image tag X from staging to prod without rebuilding."
- Write one rollback sentence: "If prod fails, redeploy tag Y."
What you see: a one-page map you can photograph for notes — useful in interviews when they ask "how do you promote?"
Ravindra Bagale's Tip
"CI green" = tests pass — prod safe nahi automatically. Migrations, seed data, cache, aani traffic shape staging madhe bagha. Bilkul visru naka!