# CI/CD Fundamentals for Platform Engineering > **CNPA Domain:** Platform Engineering Core Fundamentals (36%) · Continuous Delivery & Platform Engineering (16%) **Topics:** Continuous Integration Fundamentals, CI/CD Relationship Fundamentals, Continuous Integration Pipelines Overview ## Overview Continuous Integration and Continuous Delivery (CI/CD) are the engines that transform code commits into production deployments. For platform engineers, CI/CD isn't just a development tool — it is a **platform capability** that must be reliable, scalable, consistent, and secure. Platform teams abstract CI/CD complexity into golden path pipelines that developers can use without needing deep pipeline expertise. *** ## Continuous Integration (CI) **Continuous Integration** is the practice of automatically integrating code changes from multiple contributors into a shared repository several times a day. Each integration triggers an automated build and test sequence. ### CI Goals * Detect integration issues early (minutes, not days) * Maintain a consistently buildable main branch * Provide fast feedback to developers * Produce verified, versioned artifacts ### The CI Pipeline ``` Code Push / PR ↓ [Trigger: GitHub Actions / Tekton / Jenkins X] ↓ ┌─────────────────────────────────────────┐ │ CI Pipeline │ │ │ │ 1. Checkout source code │ │ 2. Install dependencies │ │ 3. Lint & static analysis │ │ 4. Unit tests │ │ 5. Integration tests │ │ 6. Build container image │ │ 7. Scan image for vulnerabilities │ │ 8. Push image to registry │ │ 9. Publish test reports │ └─────────────────────────────────────────┘ ↓ Artifact: Versioned container image ``` ### Pipeline-as-Code All CI pipelines should be defined as code, stored alongside the application: ```yaml # .github/workflows/ci.yaml (GitHub Actions example) name: CI Pipeline on: push: branches: [main] pull_request: branches: [main] jobs: build-and-test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run unit tests run: make test - name: Build container image run: | docker build -t $IMAGE_NAME:${{ github.sha }} . - name: Scan for vulnerabilities uses: aquasecurity/trivy-action@master with: image-ref: ${{ env.IMAGE_NAME }}:${{ github.sha }} exit-code: '1' severity: 'CRITICAL,HIGH' - name: Push to registry run: docker push $IMAGE_NAME:${{ github.sha }} ``` *** ## Continuous Delivery vs Continuous Deployment These terms are often confused: | Term | Definition | Human Gate | | ------------------------- | ------------------------------------------------------------------------------- | ---------- | | **Continuous Delivery** | Every change is *releasable* automatically; deployment requires manual approval | ✅ Yes | | **Continuous Deployment** | Every change that passes tests is deployed to production automatically | ❌ No | Most mature organizations practice **Continuous Delivery** (with automated deploy to staging, manual approve to production). ``` CI Pipeline → staging (auto) → [manual approve] → production ``` *** ## CD Pipeline Stages ``` Verified Artifact (container image) ↓ [CD Trigger: GitOps tool / Argo CD / Flux] ↓ ┌──────────────────────────────────────────────┐ │ CD Pipeline │ │ │ │ 1. Update manifest/Helm values in Git │ │ 2. Deploy to staging environment │ │ 3. Run smoke tests / integration tests │ │ 4. Await approval (for production) │ │ 5. Deploy to production environment │ │ 6. Run post-deployment health checks │ │ 7. Notify on Slack / PagerDuty │ └──────────────────────────────────────────────┘ ``` *** ## CI/CD in the Platform Engineering Context ### Platform Team Responsibilities Platform teams don't just run CI/CD — they **provide CI/CD as a platform capability**. | Responsibility | Description | | ------------------------- | --------------------------------------------------- | | **Golden path pipelines** | Reusable pipeline templates developers extend | | **Shared runners/agents** | Centrally managed, auto-scaled build infrastructure | | **Registry management** | Container registries, OCI artifact stores | | **Pipeline security** | Secrets injection, OIDC, signed artifacts | | **Observability** | Pipeline metrics, failure alerting, DORA metrics | ### CI/CD as a Self-Service Capability A mature platform exposes CI/CD through a **service catalog** with standardized pipelines: ``` Developer in Backstage: → Creates new service from template → Platform auto-provisions: • GitHub repository with CI workflow • Container registry namespace • ArgoCD Application • Slack deployment notifications → Developer pushes code → pipeline runs ``` *** ## Key CI Concepts ### Build Artifacts and Versioning All artifacts produced by CI should be: * **Immutable** — never overwrite a tag (use the commit SHA) * **Traceable** — tag contains metadata linking back to the source commit * **Scanned** — verified for vulnerabilities before deployment ``` registry.example.com/payment-service:abc1234 ← SHA-based (immutable) registry.example.com/payment-service:2.1.0 ← Semantic version registry.example.com/payment-service:latest ← ⚠️ Avoid in production ``` ### Test Pyramid in CI ``` ╱╲ ╱E2E╲ ← Slow, few, expensive ╱──────╲ ╱Integration╲ ← Medium speed and count ╱──────────────╲ ╱ Unit Tests ╲ ← Fast, many, cheap ╱──────────────────╲ ``` CI pipelines should run unit tests on every commit (fast feedback), integration tests on PRs, and E2E tests on merge to main. ### Fail Fast Principle Order CI stages from fastest to slowest: 1. Lint / format check (seconds) 2. Unit tests (seconds to minutes) 3. Build (minutes) 4. Integration tests (minutes) 5. Security scans (minutes) Stop on first failure to save time and resources. *** ## CI/CD Tools in Platform Engineering | Tool | Type | Notes | | ------------------ | ---------------------- | ------------------------------------------ | | **GitHub Actions** | CI/CD | Cloud-native, YAML workflows, OIDC support | | **Tekton** | CI (Kubernetes-native) | Pipeline CRDs, cloud-agnostic | | **Jenkins X** | CI/CD | Kubernetes-native Jenkins replacement | | **Argo Workflows** | CI / Batch | Kubernetes workflow engine | | **Argo CD** | CD (GitOps) | Git-based continuous delivery | | **Flux** | CD (GitOps) | Kubernetes-native GitOps controller | *** ## DORA Metrics: Measuring CI/CD Performance The [DORA metrics](https://dora.dev/) are the standard for measuring software delivery performance: | Metric | What It Measures | Elite Target | | ------------------------- | ---------------------------------- | ------------ | | **Deployment Frequency** | How often you deploy | Multiple/day | | **Lead Time for Changes** | Code commit → production | < 1 hour | | **Change Failure Rate** | % of deployments causing incidents | < 5% | | **Time to Restore** | Incident detection → recovery | < 1 hour | Platform teams improve all four metrics by providing reliable, fast CI/CD infrastructure and golden path pipelines. *** ## Key Takeaways * CI integrates code changes automatically and produces verified artifacts on every commit * **Pipeline-as-code** stored in version control ensures reproducibility and auditability * CD automates deployment through environments; **Continuous Delivery** retains a human gate to production * Platform teams provide CI/CD as a **self-service platform capability** via golden path templates * Use commit SHA image tags (immutable), run tests in **fail-fast order**, and scan images before deployment * DORA metrics measure the health of your CI/CD capability *** ## Further Reading * [DORA State of DevOps Report](https://dora.dev/) * [GitHub Actions Documentation](https://docs.github.com/en/actions) * [Tekton Pipelines](https://tekton.dev/) * [Continuous Delivery Pipelines - jez.io](https://jezhumble.net/) * → Next: [GitOps Basics and Workflows](https://blog.htunnthuthu.com/getting-started/fundamentals/platform-engineering-101/platform-engineering-101-gitops)