CI/CD Pipeline Fundamentals for Kubernetes: Workflow, Tool Comparison, and Practical Starter Config

A reliable CI/CD pipeline turns code changes into repeatable, low-risk releases. This guide is for DevOps engineers and platform teams who want a practical baseline for building, testing, and deploying containerized applications, with clear gates for quality and production safety.

Originally published on 2009-03-27; fully revised and updated.

What a practical CI/CD pipeline includes

A production-ready pipeline is more than a build script. It should enforce consistent checks, produce traceable artifacts, and support safe rollouts with rollback options.

• Source stage: trigger on pull requests and protected branches.
• Continuous integration stage: run linting, unit tests, and optionally security checks.
• Artifact stage: build immutable artifacts (such as container images) and push to a registry.
• Continuous delivery stage: deploy to staging automatically, then promote to production with policy controls.
• Post-deploy stage: verify health, monitor metrics/logs, and enable quick rollback.

Reference workflow from commit to production

This flow is a strong default for teams running containerized workloads on Kubernetes.

flowchart TD
    A[Developer pushes commit] --> B[CI runs lint and unit tests]
    B --> C{Checks pass}
    C -- no --> D[Fail pipeline and notify team]
    C -- yes --> E[Build container image]
    E --> F[Push image to registry]
    F --> G[Deploy to staging]
    G --> H[Run integration tests]
    H --> I{Approved for production}
    I -- no --> J[Stop release and investigate]
    I -- yes --> K[Deploy to production]
    K --> L[Monitor and rollback if needed]

Choose a pipeline platform that matches your operating model

Different teams optimize for different constraints: speed of setup, UI experience, plugin ecosystem, Kubernetes-native execution, or enterprise control.

Example baseline configuration for a containerized service

The following examples show a minimal pattern: test first, then build, then deploy to staging. Treat them as a starting point and adapt to your runner, registry, and environment controls.

Sample CI workflow file

name: app-ci-cd

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Bootstrap
        run: ./scripts/bootstrap.sh
      - name: Lint
        run: ./scripts/lint.sh
      - name: Unit tests
        run: ./scripts/test.sh

  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t registry.example.com/demo-app:${{ github.sha }} .
      - name: Push image
        run: docker push registry.example.com/demo-app:${{ github.sha }}

  deploy_staging:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to staging
        run: ./scripts/deploy.sh staging ${{ github.sha }}Code language: HTTP (http)

Sample Kubernetes deployment commands

set -euo pipefail

NAMESPACE=prod
APP=demo-app
IMAGE=registry.example.com/demo-app:${1}

kubectl -n ${NAMESPACE} set image deployment/${APP} app=${IMAGE}
kubectl -n ${NAMESPACE} rollout status deployment/${APP} --timeout=180s
kubectl -n ${NAMESPACE} get pods -l app=${APP}

# Roll back quickly if needed
kubectl -n ${NAMESPACE} rollout undo deployment/${APP}

Release gates that improve safety early

Teams often focus first on build speed, but release reliability usually improves most when quality gates are explicit and automated.

• Require pull requests and protected branches for production paths.
• Block artifact publication if unit tests or lint checks fail.
• Add integration tests in staging before production promotion.
• Use environment-specific approvals for high-impact services.
• Capture deployment metadata (commit SHA, image tag, timestamp) for traceability.

Best practices

• Keep pipelines small and composable; split long jobs into reusable stages.
• Prefer immutable artifacts and promote the same image across environments.
• Standardize rollback commands and test rollback procedures regularly.
• Store secrets in a dedicated secret manager, not directly in pipeline files.
• Version your pipeline definitions and review them like application code.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.