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:

# .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:

Lint / format check (seconds)
Unit tests (seconds to minutes)
Build (minutes)
Integration tests (minutes)
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 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

hashtagOverview

hashtagContinuous Integration (CI)

hashtagCI Goals

hashtagThe CI Pipeline

hashtagPipeline-as-Code

hashtagContinuous Delivery vs Continuous Deployment

hashtagCD Pipeline Stages

hashtagCI/CD in the Platform Engineering Context

hashtagPlatform Team Responsibilities

hashtagCI/CD as a Self-Service Capability

hashtagKey CI Concepts

hashtagBuild Artifacts and Versioning

hashtagTest Pyramid in CI

hashtagFail Fast Principle

hashtagCI/CD Tools in Platform Engineering

hashtagDORA Metrics: Measuring CI/CD Performance

hashtagKey Takeaways

hashtagFurther Reading