> ## 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 Delivery and GitOps Fundamentals
> Overview of continuous delivery and GitOps practices for automating immutable artifact promotion, declarative Git-driven deployments, progressive rollouts, migration safety, policy gates, and platform observability.
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.
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.
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.
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:
| Component | Purpose | Examples |
| - | - | - |
| Git repositories | Store application and infrastructure manifests as source of truth | `git` (app repos vs infra repos) |
| GitOps controllers | Reconcile Git → cluster state, pull-based sync | Argo CD, Flux v2, Rancher Fleet |
| Artifact registries | Store immutable images/binaries referenced by manifests | Harbor, ECR, GCR, Docker Hub |
| CI/CD orchestration | Build artifacts and optionally update Git manifests | GitHub Actions, Jenkins, GitLab CI |
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.
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.
Immutability and artifact promotion
* Build once, promote the exact same artifact across environments to minimize risk.
Example artifact reference:
```text theme={null}
CI Build
pony-spawner:sha-abc123
```
Using the identical SHA in dev, staging, and production ensures tests and releases operate on the same binary.
Progressive delivery strategies
Choose the strategy that matches your risk profile and traffic characteristics.
| Strategy | How it works | Use case / Tradeoffs |
| - | -: | - |
| Canary | Send a small percentage (e.g., 1–5%) to new version, monitor, then increase | Low initial exposure, good for quick validation |
| Linear | Increase traffic by fixed increments (e.g., +10% every X minutes) | Predictable ramp; schedule-based |
| Blue-Green | Deploy parallel environment, switch 100% traffic when ready | Quick full cutover and rollbacks; requires duplicate infra |
Plan percentages and timing against actual traffic volume and SLAs, and always combine rollouts with health checks and automated rollback triggers.
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.
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.
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.
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.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.