> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Applications Environments Infrastructure Concepts > Overview of environment tiers, infrastructure as code, continuous promotion, capacity governance, and platform engineering practices for reliable software delivery across development, test, staging, and production Welcome back. This lesson explains application environments and the underlying infrastructure concepts platform engineers use to ensure reliable software delivery. Focus areas include environment tiers, resource governance, capacity planning, and the historical influence of Site Reliability Engineering (SRE) and DevOps on platform practices. Consistency across environments is essential for availability, security, and predictable operations. At the same time, when running a shared platform we must isolate applications and environment tiers so development issues do not impact production. That implies we need to balance: * Architectural parity (consistency) across environments * Isolation between environment tiers * Distinct resource policies and access controls for development vs production Non-production environments still require service-level expectations. If a test or staging environment is down, developers can’t verify features and releases — causing real business impact. Treat non-prod availability, access, and observability as operational responsibilities. Environment progression (continuous promotion) commonly follows this flow: local development (developer workstations) → shared development / integration → CI-driven test/QA → staging / pre-production (UAT, performance testing) → production (possibly multi-region). Each promotion step should run in an environment as similar to production as is practical. Maintain at least one or two production-like environments to prototype changes and reproduce incidents without risking live systems. A vertical infographic of four stacked colored cubes numbered 1–4 representing software environments: Development, Test, Staging, and Production, each with a short description of its purpose. ## Environment tiers and recommended practices Below is a concise reference of common environment tiers, their purpose, and typical practices platform teams apply to each. | Environment | Purpose | Recommended practices | | - | - | - | | Development | Fast local iteration and feature development | Use local Kubernetes (e.g., [KinD](https://kind.sigs.k8s.io/), [Minikube](https://minikube.sigs.k8s.io/), Docker Desktop, Rancher Desktop) or containers (Podman). Prioritize fast feedback, ephemeral namespaces, and lightweight resource quotas. | | Shared Development / Integration | Early integration testing across teams | Mirror production architecture where possible, reset environments regularly to prevent configuration drift, and apply resource quotas to avoid runaway usage. | | Test / QA | Automated validation via CI | Run unit, integration, and E2E tests; add static analysis, dependency and security scanning. Keep architecture similar to production but usually at reduced capacity; enforce strict resource limits and controlled access. | | Staging / Pre-Production | Final validation, performance and security testing | Nearly identical architecture and data characteristics to production; run full-capacity performance/load tests (ephemeral if cost-prohibitive), and validate deployment strategies (canary/blue-green). | | Production | Live user traffic and operations | Highest operational rigor: monitoring, alerting, capacity planning, multi-region/AZ patterns, and controlled rollout strategies. | Development Development typically begins on developer workstations. Common workflows use lightweight Kubernetes distributions or container engines for local parity with production. Developers iterate rapidly through build → run → debug cycles, and teams often maintain shared development environments for early integration. Shared development environments should: * Match production architecture where practical (not necessarily capacity) * Be periodically reset to prevent configuration drift * Enforce resource quotas to contain costs and noisy neighbors * Prioritize short feedback cycles over full-scale testing A presentation slide titled "Development: Fast Feedback and Early Integration" showing a local development workflow with a circular gear icon and arrows labeled Build → Run → Debug, emphasizing fast feedback and minimal constraints. ## Test / QA CI/CD pipelines promote artifacts into test environments where automated unit, integration, and end-to-end tests run. This stage also runs static analysis, linting, dependency checks, and security scans. Test/QA environments should be as production-like as practical in architecture but are often scaled down in capacity. For QA/UAT: * Use sanitized or redacted production-like data when required * Limit access (network/VPN controls and role-based permissions) * Reset or resynchronize state regularly to keep tests representative Manual testing still has value, but over-reliance on manual QA for core validation reduces scalability and reproducibility. Automate CI-driven validation where possible and reserve manual testing for human workflows, accessibility checks, or final UAT sign-off. A presentation slide titled "Test and QA: Automated Validation and Human Verification" with two boxes comparing environments. The left box describes CI-driven test environment practices (ephemeral namespaces, automated unit/integration/end-to-end tests, strict resource limits) and the right box lists QA/UAT items (manual validation, production-like sanitized data, controlled network/VPN access). Staging / Pre-Production Staging (pre-production) should closely match production in architecture, configuration, and data characteristics. This environment is ideal for deep security scans, performance and load testing, and final validation before production. Key staging practices: * Run production-like capacity for meaningful performance tests * Use production or appropriately sanitized production data * Validate deployment strategies (canary, blue/green, rolling) * Prefer ephemeral, on-demand provisioning in cloud environments to optimize costs A presentation slide titled "Staging and Production: Final Validation and Live Operations" showing three colored blocks for Staging/Pre-Production, Performance Testing, and Production with icons and short descriptions. The slide is branded © KodeKloud. Production Production is the live environment and must be managed with the highest operational discipline: monitoring, alerting, capacity planning, incident response, and controlled deployment strategies. Production capacity planning should drive capacity and scaling policies across lower environment tiers. Automated Environment Promotion (Continuous Promotion) Continuous promotion is the pipeline that moves code from developer commits to production. Typical pipeline stages include: | Stage | Purpose / Activities | | - | - | | Build & static checks | Compile/build artifacts, run linters, dependency checks, SAST/SCA | | Push artifacts | Publish images to container registries or other artifact stores | | Automated tests | Unit tests, integration tests, and smoke tests run in CI | | QA / UAT | Manual validation and business sign-off if required | | Staging / Pre-prod | Performance, load, and security testing in production-like environments | | Production rollout | Controlled deployment (canary, blue/green, gradual) and monitoring | Pipelines may provision ephemeral test or staging environments on demand, run tests against them, then tear them down to reduce cost and drift. A slide showing an "Automated Environment Promotion – Continuous Promotion" pipeline with vertical stages: Dev Build, Test, QA, Staging, and Production. Each stage has brief notes about activities (unit/code scans, integration tests, manual QA sign-off, performance/security tests, and blue/green or canary deployment). Platform Engineering Implications Application environments are core to platform engineering. A robust platform enables teams to provision environments self-service, test in progressively production-like environments, and focus on delivering features rather than managing infrastructure. Key platform engineering capabilities include: * Infrastructure as Code (IaC): declarative, version-controlled templates (e.g., [Terraform](https://www.terraform.io/), [AWS CloudFormation](https://aws.amazon.com/cloudformation/)) so environments are reproducible * Automated provisioning and teardown of ephemeral environments via CI/CD * Capacity monitoring, quotas, and cost governance across all tiers (including development) * Autoscaling, intelligent resource policies, and horizontal/vertical scaling strategies * Observability and access controls tailored to each environment tier Using IaC and CI/CD together enforces architectural parity while enabling different capacity and security profiles per environment. A presentation slide titled "Application Environments – Platform Engineering Foundations" with a brief line about platform engineering enabling self-service environment provisioning. Below the text is a colorful illustration of three people collaborating around a large web/app UI mockup with icons for email, settings, and user profiles. ## Quick reference: tools & examples | Category | Examples | | - | - | | Local Kubernetes | KinD, Minikube, Docker Desktop, Rancher Desktop | | Container runtimes | Docker, Podman | | IaC | Terraform, AWS CloudFormation, Pulumi | | CI/CD | Jenkins, GitHub Actions, GitLab CI, Argo CD / Argo Workflows | | Observability | Prometheus, Grafana, ELK/EFK stack, Datadog | Summary Environment progression (dev → test/QA → staging → production), infrastructure as code, automated promotion pipelines, capacity governance, and environment parity are foundational platform engineering concepts. When implemented together they let teams deliver production-quality features safely and efficiently while retaining operational control and cost discipline. Links and references * [Kubernetes Concepts — Official Docs](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/) * [Terraform — Infrastructure as Code](https://www.terraform.io/) * [CI/CD Patterns and Practices (Argo CD, GitHub Actions, GitLab CI)](https://argo-cd.readthedocs.io/) * [Site Reliability Engineering (Google SRE)](https://sre.google/) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.