10.3 Continuous Delivery, Deployment Automation & GitOps
Key Takeaways
- Continuous Delivery automates software validation through staging environments up to an authorized manual approval gate for production, whereas Continuous Deployment completely automates the release all the way to production without human intervention.
- Cloud deployment orchestration tools (AWS CodeDeploy, GitHub Actions, Azure Pipelines, GitLab CD) coordinate rollouts, infrastructure configuration, and lifecycle health checks.
- GitOps establishes a declarative paradigm where Git is the single source of truth for desired infrastructure and application state, utilizing in-cluster controllers (ArgoCD, Flux) to continuously pull state and reconcile drift.
- Pull-based GitOps architectures enhance cloud security by running agents inside the cluster network, eliminating the need to expose cluster administrative credentials to external CI/CD runner pipelines.
- Progressive delivery strategies—including Feature Flags, Blue/Green deployments, and Canary analysis—minimize blast radius by combining gradual traffic shifting with automated metric health checks and instant rollback triggers.
Continuous Delivery, Deployment Automation & GitOps
Once software artifacts are built, verified, and published by Continuous Integration pipelines, release automation systems take over to deploy, configure, and monitor applications in runtime environments. In modern cloud engineering, release strategies have evolved from error-prone manual server deployments to fully automated Continuous Delivery (CD), Continuous Deployment, and declarative GitOps architectures.
For the CompTIA Cloud+ (CV0-004) exam, candidates must master the distinction between Continuous Delivery and Continuous Deployment, understand cloud orchestration platforms, evaluate pull-based vs. push-based GitOps reconciliations, and implement Progressive Delivery techniques (Blue/Green, Canary, Feature Flags, and Automated Rollbacks).
1. Continuous Delivery vs. Continuous Deployment
While the acronym "CD" is often used generically, it refers to two distinct release automation models based on the presence or absence of a manual approval gate:
+-----------------------------------------------------------------------------------------+
| CONTINUOUS DELIVERY VS. CONTINUOUS DEPLOYMENT |
| |
| CONTINUOUS DELIVERY (Automated Staging with Manual Production Approval Gate) |
| +-----------+ +------------+ +------------+ +==========+ +----------+ |
| | Build App | --> | Auto Test | --> | Deploy to | --> | MANUAL | --> | Deploy to| |
| | & Package | | & Validate | | Staging | | APPROVAL | | Prod | |
| +-----------+ +------------+ +------------+ +==========+ +----------+ |
| |
| CONTINUOUS DEPLOYMENT (Fully Automated Direct to Production) |
| +-----------+ +------------+ +------------+ +------------+ +----------+ |
| | Build App | --> | Auto Test | --> | Deploy to | --> | Automated |-->| Deploy to| |
| | & Package | | & Validate | | Staging | | Metric Gate| | Prod | |
| +-----------+ +------------+ +------------+ +------------+ +----------+ |
| (No Manual Gate) |
+-----------------------------------------------------------------------------------------+
Detailed Comparison
| Dimension | Continuous Delivery | Continuous Deployment |
|---|---|---|
| Production Release Trigger | Manual human approval (Release Manager, Product Owner) | Fully automated immediately upon passing CI gates |
| Governance & Compliance | Ideal for heavily regulated industries (SOX, HIPAA, PCI DSS, Banking) | Ideal for cloud-native SaaS platforms, microservices, and DORA elite teams |
| Deployment Frequency | Scheduled releases (daily, weekly, on-demand) | Continuous (dozens or hundreds of releases per day) |
| Blast Radius Mitigation | Human verification of staging readiness prior to release | Progressive delivery (Canary / Feature Flags) and automated rollbacks |
2. Cloud Deployment Automation Platforms
Enterprise cloud deployments utilize specialized deployment automation services across major cloud platforms:
+-----------------------------------------------------------------------------------------+
| CLOUD DEPLOYMENT PLATFORMS TAXONOMY |
| |
| Platform Architecture Model Primary Cloud Ecosystem |
| +--------------------+--------------------------+-----------------------------------+ |
| | AWS CodePipeline / | Native Cloud Managed | AWS (EC2, ECS, Lambda, EKS) | |
| | AWS CodeDeploy | Orchestrator | | |
| | | | | |
| | Azure Pipelines | Multi-Stage YAML Cloud | Microsoft Azure, Hybrid, Multi-Cl | |
| | | CD with Release Gates | | |
| | | | | |
| | GitLab CD / | Integrated Git + Matrix | Multi-Cloud, Kubernetes, IaaS | |
| | GitHub Actions CD | Environments & Secrets | | |
| | | | | |
| | Jenkins | Self-Hosted Controller + | On-Premises, Legacy Hybrid | |
| | | Distributed Build Agents | | |
| +--------------------+--------------------------+-----------------------------------+ |
+-----------------------------------------------------------------------------------------+
Deployment Lifecycle Hooks (e.g., AWS CodeDeploy appspec.yml)
Deployment engines execute scripts at precise lifecycle phases to guarantee zero-downtime updates and automated health checks:
version: 0.0
os: linux
files:
- source: /
destination: /var/www/production-app
hooks:
BeforeInstall:
- location: scripts/deregister_from_load_balancer.sh
timeout: 300
runas: root
AfterInstall:
- location: scripts/install_dependencies.sh
timeout: 300
runas: root
ApplicationStart:
- location: scripts/start_application_service.sh
timeout: 120
runas: root
ValidateService:
- location: scripts/verify_healthcheck_endpoint.sh
timeout: 60
runas: root
3. GitOps Methodology: Declarative Infrastructure & Controllers
GitOps is an operational framework that applies DevOps best practices—such as version control, collaboration, compliance, and CI/CD—to infrastructure automation and Kubernetes application delivery. In GitOps, Git is the single source of truth for the entire system's desired state.
+-----------------------------------------------------------------------------------------+
| PUSH-BASED CD VS. PULL-BASED GITOPS |
| |
| PUSH-BASED CD (Traditional Pipeline) |
| +-----------+ +---------------+ Cluster Credentials +-------------------+ |
| | Git Repo | -------> | CI/CD Runner | ---------------------> | Kubernetes Cluster| |
| +-----------+ | (External) | (kubectl apply) | (Inbound API Open)| |
| +---------------+ +-------------------+ |
| - Security Risk: External runner stores privileged cluster administrative credentials |
| - Network Risk: Kubernetes API server must allow inbound traffic from CI runners |
| |
| PULL-BASED GITOPS (ArgoCD / Flux) |
| +-----------+ +-------------------+ |
| | Git Repo | <---------------- Pull Desired State ----------- | GitOps Controller | |
| | (Desired | (Outbound HTTPS / Read-Only) | (ArgoCD / Flux) | |
| | State) | | Inside Cluster | |
| +-----------+ +---------+---------+ |
| | |
| Reconcile | (Apply) |
| v |
| [ Live Cluster State] |
| - Zero Inbound Exposure: In-cluster operator pulls state; cluster API is private |
| - Continuous Drift Detection & Automated Self-Healing |
+-----------------------------------------------------------------------------------------+
The Four Principles of OpenGitOps
- Declarative Descriptions: The entire target system (infrastructure, networking, container workloads) must be described declaratively (e.g., Kubernetes YAML manifests, Helm charts, Kustomize overlays).
- Versioned and Immutable Storage: The canonical desired state is stored in Git, providing complete version history, change tracking, and cryptographic auditability.
- Pulled Automatically by In-Cluster Agents: Software agents running inside the target runtime continuously pull the desired state from Git.
- Continuously Reconciled with Drift Detection: The GitOps controller compares the Live State against the Desired State. If an unauthorized operator manually modifies a resource via
kubectl edit, the controller detects the drift and automatically self-heals the cluster back to the version declared in Git.
Leading GitOps Controllers
- ArgoCD: A declarative, GitOps continuous delivery tool for Kubernetes providing an intuitive web UI, visual application dependency trees, automated rollbacks, and multi-cluster management.
- Flux (FluxCD): A modular set of Kubernetes controllers (Source Controller, Kustomize Controller, Helm Controller, Notification Controller) natively integrated with the Kubernetes API.
4. Progressive Delivery: Blue/Green, Canary & Feature Flags
Progressive Delivery builds upon Continuous Delivery by combining advanced deployment strategies with fine-grained traffic routing and automated telemetry verification to minimize the blast radius of releases.
+-----------------------------------------------------------------------------------------+
| PROGRESSIVE DELIVERY STRATEGIES TAXONOMY |
| |
| Strategy Architecture & Traffic Flow Cost & Rollback Profile |
| +--------------+-----------------------------------------+--------------------------+ |
| | In-Place / | Replaces instances one-by-one in the | Lowest cost (1x infra); | |
| | Rolling | existing pool. Mixed versions active. | Slow rollback (must | |
| | | | re-roll previous image) | |
| | | | | |
| | Blue/Green | Two identical production environments. | High cost (2x infra); | |
| | | Router flips 100% traffic from Blue | Instantaneous rollback | |
| | | (v1) to Green (v2) simultaneously. | (flip router back) | |
| | | | | |
| | Canary | Routes small traffic percentage (5-10%) | Low cost (+10% infra); | |
| | Deployment | to Canary (v2); expands gradually based | Low blast radius; | |
| | | on real-time metric analysis. | automated rollback | |
| +--------------+-----------------------------------------+--------------------------+ |
+-----------------------------------------------------------------------------------------+
Feature Flags (Feature Toggles)
Feature flagging platforms (e.g., LaunchDarkly, Unleash, AWS AppConfig) separate software deployment from feature release:
- Runtime Decoupling: Code is deployed to production in a dormant state. Product managers toggle features on for specific target audiences (e.g., 5% of beta users in a specific region) via cloud APIs without redeploying containers or modifying infrastructure.
- Instant Kill Switches: If a newly activated feature causes backend database locks or unexpected errors, operators flip the flag to
falsein real time, instantly mitigating customer impact without initiating emergency code rollbacks.
Automated Canary Analysis & Rollback Architecture
Canary deployments integrate directly with monitoring and telemetry platforms (Prometheus, Datadog, AWS CloudWatch) to evaluate Service Level Indicators (SLIs):
+-----------------------------------------------------------------------------------------+
| AUTOMATED CANARY METRIC RECONCILIATION |
| |
| Step 1: Shift 5% Traffic to Canary Pods (v2.0) --------------------------------+ |
| Step 2: Monitor Real-Time Metrics for 10 Minutes: | |
| - SLI Check 1: HTTP 5xx Error Rate < 0.2% | |
| - SLI Check 2: p99 Latency < 250ms | |
| - SLI Check 3: Host CPU Saturation < 75% | |
| | |
| +--------------------------------------------------------------------------+ | |
| | IF ALL SLIs HEALTHY: | | |
| | Promote to 25% -> 50% -> 100% traffic. Terminate Baseline (v1.0). | | |
| +--------------------------------------------------------------------------+ | |
| | IF ANY SLI FAILS (e.g., 5xx Error Rate Spikes to 1.8%): | | |
| | AUTOMATED ROLLBACK: Shift 100% traffic back to Baseline (v1.0) instantly! | | |
| | Scale Canary to 0 pods; Send high-priority alert to PagerDuty / Slack. | | |
| +--------------------------------------------------------------------------+ | |
+-----------------------------------------------------------------------------------------+
5. CompTIA Cloud+ Exam Traps & Real-World Gotchas
- Continuous Delivery vs. Continuous Deployment Distinction: A frequent CompTIA Cloud+ exam question presents a scenario where an enterprise automates all testing through staging, but requires a formal change advisory board (CAB) or manager sign-off before promoting code to production. This is Continuous Delivery. If the release proceeds automatically without human intervention, it is Continuous Deployment.
- GitOps Security Posture: In traditional CI/CD, the external runner must hold high-privilege administrative credentials (such as Kubernetes
cluster-admintokens) to executekubectlcommands against the cloud cluster. In pull-based GitOps, no external credentials exist; the controller lives inside the cluster and only requires outbound read-only access to Git. - Database Schema Migrations in Blue/Green Deployments: When executing a Blue/Green traffic switch, the database is typically shared between the Blue and Green environments. Breaking schema changes (e.g., renaming a database column) will crash the live Blue environment before the Green switch occurs. Database migrations must follow the Expand/Contract (Parallel Run) Pattern, ensuring backward compatibility across both versions.
A financial cloud architect is designing a continuous deployment pipeline for a regulated payment processing microservice on a Kubernetes cluster. To satisfy zero-trust security requirements, the architect must ensure that no cluster administrative credentials or private kubeconfig files are exposed to external CI runners. Which architectural model satisfies this requirement?
An enterprise deployment pipeline automatically executes linting, unit tests, integration tests, and deploys build artifacts to a staging environment. However, promoting the release to the production cloud environment requires a manual sign-off by the release manager in the pipeline web portal. Which software release methodology is this organization practicing?
During a canary deployment of a critical web API, 10% of live customer traffic is routed to the new canary version. Five minutes post-deployment, the monitoring system records an HTTP 5xx error rate spike to 3.5% on the canary pods, exceeding the defined 0.5% SLI threshold. Which action should the automated progressive delivery controller execute immediately?