> ## 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. # Continuous DeliveryDeployment Basics > Overview of continuous delivery and deployment practices, workflows, strategies, validation gates, rollback mechanisms, feature flags, and automation for safe repeatable production releases In this lesson we cover the CD portion of the CI/CD lifecycle: how artifacts move through release environments into production, and the practices that make releases fast, safe, and repeatable. Continuous delivery and continuous deployment are related but distinct: * Continuous delivery: every change is built and kept in a deployable state. Promotion to production is possible at any time but may require a human decision or business timing. Artifacts are promoted through environments (dev → QA → staging → pre-production) and typically stop before production. * Continuous deployment: every change that passes automated gates is deployed all the way to production automatically. This requires strong automated tests, security checks, release automation, observability, and rollback processes. The image compares Continuous Delivery (CD) and Continuous Deployment, highlighting key differences such as the need for human approval and release timing in CD, versus automation and user reach in Continuous Deployment. Rollback capability is critical — it's not enough to create artifacts or backups; you must regularly test restores and rollback procedures so they work when needed. A robust rollback system often indicates a solid deployment process. Core deployment workflow A minimal, repeatable process for moving an artifact to production: * Retrieve the artifact from the artifact repository. * Target the appropriate environment (dev, QA, staging, pre-prod). * Apply environment-specific configuration (secrets, resource limits, feature flags). * Deploy or update instances/services. * Run verification (smoke tests, health checks, performance checks). * Confirm deployment success or trigger rollback. The image shows a deployment pipeline diagram, illustrating the process from artifact retrieval to health verification in a core deployment workflow. Environment progression and validation Environments and validation stages differ by organization, but a common progression is: | Stage | Purpose | Typical automated checks | | - | - | - | | Development | Iterative coding, feature development | Unit tests, linting, local integration checks | | Staging | Integrated testing with production-like config | Integration tests, end-to-end tests, smoke tests | | Pre-production | Final validation on production-like infra/data | Performance tests, security scans, data migration dry-runs | | Production | Live traffic and real users | Canary/observability checks, business KPI monitoring | Each stage should have validation gates that grow stricter as you approach production. The image depicts a progression workflow for software environments, titled "Environment Progression – Validated Path to Production," with four stages: Development, Staging, Pre-Production, and Production. Each stage is summarized with a description of its function in the software development process. Selecting a deployment strategy Choose a strategy based on risk tolerance, infrastructure capacity and cost, rollback speed, and the observability you have in place. | Strategy family | How it works | Pros | Cons | | - | -: | - | - | | In-place / Rolling updates | Replace instances progressively (one or a batch at a time) | Low infra overhead, continuous availability | Mixed-version traffic, slower rollback | | Side-by-side / Blue-green | Provision parallel environment and switch traffic | Instant rollback, clear separation | Higher infra cost | | Traffic-based (canary, A/B) | Route a small % of traffic to new version and ramp up | Limits blast radius, realistic validation | Requires traffic management and strong observability | | Time-based | Observe for a fixed duration before progressing | Adds deterministic observation window | May delay rollout, needs good metrics | The image illustrates four deployment strategy categories: In-Place, Side-by-Side, Traffic-Based, and Time-Based, each with distinct descriptions. It highlights the importance of balancing speed and safety in strategy selection. Canary deployment (example) * Start by routing a small percentage (e.g., 5–10%) of traffic to the new version. * Monitor key metrics (error rates, latency, business KPIs). * Gradually increase traffic if metrics remain healthy; abort and roll back on degradation. This approach provides controlled exposure and fast rollback when issues appear. The image outlines the Canary Deployment process for risk mitigation through gradual exposure, consisting of traffic splitting, metrics monitoring, and gradual increase. The image describes a canary deployment strategy involving risk mitigation through gradual exposure. It outlines steps to start with 10% of users, ensure everything works well, slowly increase to more users, and limit problems affecting only a few users. Feature flags * Allow shipping code that is disabled or hidden until toggled on. * Enable targeted rollouts, A/B tests, and immediate disablement when issues occur. * Combine feature flags with canary or traffic strategies for finely controlled rollouts. The image outlines four core capabilities of feature flags: deploying without exposing, targeted rollouts, instant control, and A/B testing. Progressive delivery Progressive delivery blends automated canaries, feature flags, strong observability, and automated rollback to let teams release quickly while minimizing risk. The image illustrates progressive delivery strategies, including automated canary, feature flags, observability, and automated rollback. Each strategy is described with short explanations of their purposes. Automate everything you can * Automate configuration management, orchestration, and health monitoring to reduce human error and toil. * Define explicit failure triggers in quality gates (smoke tests, performance tests, security checks, business validation) so rollbacks or pauses are automatic when thresholds are breached. * Measure rollback cost in time, money, and resources to choose appropriate strategies. The image outlines three areas of deployment automation: Configuration Management, Orchestration, and Health Monitoring, each aimed at reducing human error and toil. Deployment quality gates * Typical gates: smoke tests, performance tests, security checks, and business validation. * If a gate fails, either automatically rollback or pause promotion for manual review, depending on policy. The image illustrates "Deployment Quality Gates" with four steps: Business Validation, Security Checks, Performance Tests, and Smoke Tests, emphasizing safe releases. It notes that gate failure triggers an automatic rollback or pauses deployment for manual checks. Rollback options * Traffic redirection: route traffic back to the previous environment. * Feature toggles: disable the new feature instantly. * Version rollback: redeploy a known-good version. * Partial rollback: scale down the fraction of systems or traffic receiving the change. The image outlines four rollback strategies for recovery: Traffic Redirection, Feature Toggle, Version Rollback, and Partial Rollback. Each strategy includes a brief description of its function. Environment-specific configuration * Keep environment files, secrets, and resource limits appropriate and versioned for each environment. * Feature flags, API keys, database endpoints, and capacity settings typically differ between environments and must be managed securely. * Treat database migrations as first-class changes: coordinate, version, and test migrations to avoid release failures. The image outlines aspects of configuration management for environment-specific deployment, including environment files, secret management, feature flags, and resource limits. Orchestration and platform tooling Orchestrators and platform services automate release workflows, approvals, access control, audit logging, and runtime security. Tools like [Spinnaker](https://spinnaker.io/) and other release orchestration platforms help ensure only approved and tested artifacts reach production, and they automate rollbacks and cross-region coordination. Team roles in a platform context | Role | Primary focus | Responsibilities | | - | -: | - | | SREs | Reliability and runbooks | Ensure deployments meet SLA/rollback requirements; own incident response | | Infrastructure / Platform engineers | Capacity, security, orchestration | Provide validated platform services, access controls, and automation | | Developers / Product teams | Features and business outcomes | Control feature flags, coordinate release timing, and validate business metrics | The image illustrates team roles in deployment from a platform engineering perspective, featuring three roles: Swati (SRE Focus), Alan (Infrastructure Focus), and Phuong (Developer Focus), along with their respective responsibilities. Key takeaways * Artifact deployment across environments is the heart of CD/CD processes. * Continuous delivery keeps artifacts production-ready; continuous deployment pushes approved changes to production automatically. * Common deployment approaches: rolling, blue-green, canary (traffic-based), feature flags, linear/in-place, and batch updates. Each balances cost, safety, and speed. * Make validation and automated quality gates progressively stricter from dev → production. * Prioritize rollback capability: deployability is valuable, but fast, tested recovery is essential. * Track metrics and observability for every deployment; use them to trigger automated rollbacks where appropriate. * Manage configuration and secrets per environment; treat migrations with the same discipline as code. * CI/CD automation is core to internal developer platforms and platform engineering—enabling frequent, safe, low-effort releases. The image outlines key takeaways for modern continuous delivery, emphasizing rollback capabilities, deployment observability, configuration management, and release orchestration. Bottom line Continuous delivery and continuous deployment enable rapid, safe releases with minimal manual effort when backed by automated gates, robust rollback strategies, environment-aware configuration management, and strong observability. This is the core promise of platform engineering: secure, testable, high-quality releases into production. Links and references * [Kubernetes Documentation](https://kubernetes.io/docs/) * [Spinnaker](https://spinnaker.io/) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.