Deployment environment Study Guide

📖 Core Concepts Environment / Tier – A distinct set of hardware/software where a specific version of an application lives (e.g., Development, Testing, Production). Phased Deployment – Moving code through a predefined sequence of environments to catch bugs early and enable safe rollback. Rollback – Re‑deploying the previous stable release as if it were a new build when a problem is detected. Canary Release – Deploying to a small subset of users/instances first, then gradually expanding if no issues appear. Feature‑Flag Flip – Turning new functionality on or off at runtime without redeploying code. 📌 Must Remember Four‑tier flow: Development → Testing → Model → Production. Alternate flow: Development → Testing → Acceptance → Production. Staging ≈ Production – Staging mirrors production exactly (including live services) for final validation. Hotfix/Patch/Service Pack – Emergency changes that skip the full staged flow. Disaster Recovery (DR) – Holds an exact (or near‑exact) copy of production for immediate fallback. Rollback technique: Deploy old version as a new release; no special “undo” command needed. 🔄 Key Processes Code Commit → CI Build Developer pushes to repository → CI system builds a clean copy in an integration environment. Promotion Pipeline Development → unit‑test → Testing (functional, performance, UI) → auto‑promote on pass → Staging → validation of install/config scripts, load testing → Production (deploy, monitor, possibly phased). Canary / Phased Rollout Deploy to 1‑N instances or % of users → monitor → if green, double the rollout size until full coverage. Rollback Detect failure → trigger monitoring alert → redeploy previous build to the same tier (often Production) → switch traffic back. 🔍 Key Comparisons Development vs. Testing Dev: local tools, compiler versions, code authoring. Test: isolated environment for QA, automated tests, detailed logs. Staging vs. Production Staging: mirrors production, may use live DB copies, no real end‑user traffic. Production: live end‑user traffic, highest risk, requires monitoring & rollback plans. Hotfix vs. Regular Release Hotfix: urgent, skips full pipeline, limited scope. Regular: follows full Dev → Test → Staging → Prod flow. Disaster Recovery vs. Backup DR: ready‑to‑run duplicate of production for immediate failover. Backup: data snapshot, not necessarily a runnable environment. ⚠️ Common Misunderstandings “Testing = QA” – Testing environments also host automated CI tests; QA is a subset focused on acceptance. “Staging is optional” – Skipping staging removes the safety net of a production‑like validation, increasing rollout risk. “Rollback restores the exact previous state automatically” – You must explicitly redeploy the prior version; config drift can still cause issues. “Hotfixes don’t need testing” – Even urgent fixes should run at least a smoke test in a testing environment. 🧠 Mental Models / Intuition “Assembly line” model: Imagine code moving down a conveyor belt (Dev → Test → Staging → Prod). Each station must verify quality before the item proceeds. “Safety net” analogy: Staging is the net that catches bugs that escaped earlier stations; if the net has holes (i.e., not a true mirror), the fall can be fatal in Production. “Traffic light” for rollouts: Green = go, Yellow = limited canary, Red = stop & rollback. 🚩 Exceptions & Edge Cases Experimental / Sandbox releases are terminal – they never move to Production. Disaster Recovery activation may require DNS or load‑balancer switchover, not just code redeployment. Feature‑flag flip can enable a new feature without a new deployment, but flag logic must be tested in all environments. 📍 When to Use Which Use a Staging environment when you need to validate installation scripts, database migrations, or integration with live services before Production. Use a Canary release for high‑impact changes or when you lack confidence in the new version’s stability. Use Hotfix/Patch process for critical bugs that cannot wait for the next scheduled release cycle. Use Disaster Recovery only when Production is unavailable or catastrophically degraded. 👀 Patterns to Recognize “Fail fast, rollback faster” – Look for automated alerts and immediate rollback triggers in deployment pipelines. “Mirror, mirror” – Staging environments almost always mention “exact duplicate” of production; any deviation is a red flag. “Parallel installation + switch” – Presence of a switch‑flip mechanism indicates a zero‑downtime deployment strategy. 🗂️ Exam Traps Distractor: “Testing environment is the same as Production.” – Wrong; testing isolates changes and provides logs without end‑user impact. Distractor: “Hotfixes must always go through Staging.” – Not required; hotfixes can bypass staged flow for speed. Distractor: “Rollback restores previous database state automatically.” – Rollback redeploys code; database state must be handled separately (e.g., via backups). Distractor: “Disaster Recovery is just another name for Staging.” – DR is a ready‑to‑run production replica for failover, not a pre‑production test bed.