Skip to main content
Welcome. This lesson extends continuous integration (CI) into the practices of continuous delivery (CD) and GitOps so you can reliably promote software from build to production with automation, traceability, and safety. We covered building, testing, publishing, and distributing artifacts in CI. After artifacts land in a registry, you need an automated, auditable way to:
  • Promote the same immutable artifact through environments (development → QA → staging → production).
  • Run environment‑specific validation (smoke tests, capacity/scalability tests, health checks).
  • Update deployment manifests and GitOps configuration so clusters reconcile to the desired state.
This combination of CD and GitOps is how teams safely deliver software at scale.
A slide titled "CD Pipeline – From CI Success to Live Deployment" showing the five key stages: Artifact Promotion, Manifest Updates, GitOps Reconciliation, Automated Validation, and Progressive Deployment, each with a short description.
Goals of an automated path to production:
  • Minimize manual intervention (especially for Kubernetes operations).
  • Bake safety and operational checks into the pipeline.
  • Enable automated rollback and progressive rollout strategies when failures occur.
A presentation slide titled "Continuous Delivery – Automated Path to Production" showing four colored items: Immutable Artifacts, Automated Promotion, Environment Parity, and Safe Rollbacks, each with a short explanatory note. The items describe testing the same artifact, dev→test→staging promotion, consistent deployment scripts, and reversible deployments.
Database and other stateful-system considerations
  • Treat database migration scripts and versioned schemas as first-class artifacts.
  • Use automated, versioned migrations that are coordinated with application deployments.
  • Prefer backward-compatible migration patterns (expand → migrate → contract) and combine them with feature flags to avoid downtime.
Database migrations are high risk. Automate and version migrations alongside the application, and validate them with safety patterns (expand-then-migrate-then-contract, feature flags, ordered releases) to avoid outages.
GitOps — four core principles
  1. Declarative configuration — manifests in Git are the single source of truth.
  2. Automated reconciliation — cluster-side controllers continuously sync live state to the desired state in Git.
  3. Pull-based deployments — controllers pull and apply changes securely from Git into clusters.
  4. Complete audit trail — commits and pull requests provide traceability for every change.
A presentation slide titled "GitOps – Declarative Operations Through Version Control" showing four pillars (Declarative, Automated Reconciliation, Pull‑Based Deployments, Complete Audit Trail) with colorful icons and brief explanatory text under each.
How GitOps works in practice
  • Store declarative manifests in Git.
  • Run a GitOps controller (Argo CD, Flux, Rancher Fleet) inside each cluster.
  • The controller pulls repositories and reconciles live cluster state to match Git.
  • CI pipelines produce immutable artifacts and can update manifests in Git to reference those artifacts, which triggers reconciliation.
Example workflow:
  • Alan (infra engineer) needs to scale a database → he commits Terraform changes to Git.
  • An automation tool or controller runs terraform apply (via CI job, Atlantis, or a Terraform controller) so the change is applied reproducibly and auditable.
GitOps architecture typically includes the following components:
A slide titled "GitOps Architecture: Repositories, Controllers, and Workflows" showing four panels: Git Repositories, GitOps Controllers, Artifact Registry, and CI/CD Orchestration. Each panel lists examples and brief notes (e.g., Argo CD/Flux v2 for controllers, Harbor/ECR/GCR for registries).
Integration patterns
  • CI-only heavy: CI server updates manifests and triggers deployments directly.
  • GitOps-first: CI produces artifacts and updates Git; controllers pull from Git and reconcile.
  • Hybrid: CI produces immutable artifacts and updates Git; controllers perform the actual cluster sync and policy enforcement.
Typical CI → GitOps flow
  1. Developer pushes a feature branch.
  2. CI runs tests and builds an immutable artifact.
  3. CI merges into main and tags the artifact (immutable SHA).
  4. CI updates the deployment manifest in the GitOps repository to reference that artifact SHA.
  5. GitOps controller detects the manifest change and reconciles the cluster, optionally performing policy checks, health probes, and progressive promotions.
An infographic titled "GitOps in Action — From Code Commit to Live Deployment." It shows a multistep CI/CD pipeline with colored chevrons and labeled stages like Developer Push, CI Pipeline, GitOps Update, Argo CD Sync, Validation, and Promotion.
Choosing a controller and platform tooling
  • Argo CD: strong UI, app-centric model, good for teams that want a user-friendly dashboard.
  • Flux v2: Git-centric, Kubernetes-native design, integrated with Helm/Kustomize.
  • Rancher Fleet: multi-cluster large-scale management.
Build servers (Jenkins, GitHub Actions, GitLab CI, etc.) can orchestrate CI tasks, but dedicated GitOps controllers simplify pull-based reconciliation and ongoing cluster drift detection.
A presentation slide titled "GitOps Controllers: Argo CD, Flux, and Platform Integration" showing three columns for Argo CD, Flux v2, and Rancher Fleet with each logo and short feature bullets (dashboard UI, Helm/Kustomize support, multi-cluster focus, enterprise/large-scale deployments). The slide is © KodeKloud.
Immutability and artifact promotion
  • Build once, promote the exact same artifact across environments to minimize risk.
Example artifact reference:
Using the identical SHA in dev, staging, and production ensures tests and releases operate on the same binary.
A slide titled "Artifact Promotion – Same Binary, Different Environments" showing four colored boxes (CI Build, Dev, Staging, Production) that illustrate promoting the same artifact SHA across dev, staging, and production environments.
Progressive delivery strategies Choose the strategy that matches your risk profile and traffic characteristics. Plan percentages and timing against actual traffic volume and SLAs, and always combine rollouts with health checks and automated rollback triggers.
A slide titled "Progressive Delivery – Minimizing Risk With Gradual Rollouts" showing three colored boxes for 20%, 50%, and 100% traffic. The stages are labeled as initial canary deployment, expanded rollout after validation, and full deployment if metrics remain healthy.
Security and policy gates
  • PR validation: run pre-merge policy checks (OPA/Rego, Conftest) and static analysis on manifests.
  • Admission control: enforce policies at apply/sync time with Gatekeeper or Kyverno.
These gates prevent unsafe or non-compliant manifests from being reconciled into clusters.
A slide titled "Security Gates — Policy Enforcement Before Deployment" showing two colored blocks: "Admission Control" (Gatekeeper validates at cluster apply time) and "PR Validation" (OPA policies check manifests before merge). Copyright KodeKloud appears at the bottom.
Key CD metrics to monitor
  • Deployment frequency — how often you deploy to production.
  • Lead time for changes — time from commit to production (hour-level targets are common).
  • Change failure rate / rollback rate — target high success rates (e.g., >95% without rollback).
  • Time to restore — how quickly you remediate failed deployments.
Infrastructure drift and environment management
  • If all changes flow through Git and controllers reconcile state, drift should be rare. Teams can and do operate without manual server logins by using declarative tooling and APIs.
  • Version environment manifests and use automated promotion to keep environments consistent, while preserving the ability to apply emergency fixes and environment-specific controls.
A slide titled "Managing Multiple Environments With GitOps" showing a central "Deployment Strategy" box. Colored nodes connected to it are labeled Environment Separation, Emergency Fixes, Automated Promotion, Production Controls, and Balanced Architecture.
Platform deployment — eat your own dog food
  • Put platform configuration and manifests in Git; treat the platform like any customer workload.
  • Automate platform deployment and testing so the platform is reproducible and versionable.
A presentation slide titled "CD and GitOps – Platform Deployment Foundation" showing four numbered pillars: 01 Automated Deployment, 02 Git as a Source of Truth, 03 Immutable Promotion, and 04 Progressive Delivery. Each pillar has a short explanatory blurb and the slide is © KodeKloud.
Final advice for platform engineering and certification prep
  • Treat CD and GitOps as foundational: they transform manual, high-risk ops into low-risk automated workflows.
  • Design pipelines with immutability, progressive delivery, policy gates, and observability built in.
  • Track CD metrics and iterate on rollout strategies to match your organizational risk tolerance.
Key takeaways: automate repeatable deployments, use Git as the source of truth, promote immutable artifacts, enforce policy gates, and measure CD outcomes (deployment frequency, lead time, change failure rate).
Thank you for reading this lesson on CD and GitOps fundamentals. This concludes Domain 1. Continue with the subsequent materials to continue preparing for the certification.

Watch Video