Kubernetes CI/CD Pipeline: A Complete Setup Guide

Deploying to Kubernetes manually is a recipe for drift, misconfigurations, and 3 AM incidents. A well-built CI/CD pipeline eliminates all three — every change is tested, containerized, and rolled out through the same automated path.

This guide walks through a production-grade pipeline using GitHub Actions for CI, ArgoCD for GitOps-based delivery, and Helm for templating.

Architecture Overview

The flow looks like this:

1. Developer pushes code to GitHub
2. GitHub Actions runs tests, builds a Docker image, pushes to a container registry
3. A bot updates the Helm values file with the new image tag
4. ArgoCD detects the change and syncs the cluster

The key insight: your Git repository is the single source of truth for what's running in production. ArgoCD watches the repo and reconciles the cluster to match.

Step 1: CI with GitHub Actions

Your CI pipeline handles testing and image building. Here's a minimal workflow:

name: CI
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run tests
        run: npm test

      - name: Build and push Docker image
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/your-org/app:${{ github.sha }}

      - name: Update Helm values
        run: |
          cd deploy/helm
          yq e '.image.tag = "${{ github.sha }}"' -i values.yaml
          git add values.yaml
          git commit -m "chore: bump image to ${{ github.sha }}"
          git push

This builds on every push to main, tags the image with the commit SHA (immutable, traceable), and updates the Helm chart automatically.

Step 2: Helm Chart Structure

Keep your Helm charts in the same repo or a dedicated deploy repo. A minimal structure:

deploy/helm/
├── Chart.yaml
├── values.yaml
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── ingress.yaml

In values.yaml:

image:
  repository: ghcr.io/your-org/app
  tag: "latest"
  pullPolicy: IfNotPresent

replicas: 3

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 512Mi

The CI pipeline updates only the tag field. Everything else is managed through pull requests — infrastructure changes go through code review just like application code.

Step 3: ArgoCD for GitOps Delivery

ArgoCD watches your Git repo and syncs changes to the cluster. Install it with:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Then create an Application resource:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/app
    targetRevision: main
    path: deploy/helm
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

The automated sync policy means ArgoCD will automatically apply changes when it detects a new commit. selfHeal: true ensures that manual kubectl changes get reverted — the Git repo always wins.

Step 4: Rollback Strategy

With this setup, rollback is just a Git revert:

git revert HEAD
git push

ArgoCD picks up the revert commit and syncs the previous image tag back to the cluster. No kubectl commands, no SSH into nodes, no panic.

For faster rollback, ArgoCD also supports one-click rollback in its UI to any previous sync state.

Best Practices

Image scanning: Add Trivy or Grype to your CI pipeline to scan images before pushing. Fail the build on critical vulnerabilities.

Canary deployments: Use Argo Rollouts alongside ArgoCD for progressive delivery. Route 5% of traffic to the new version, monitor error rates, then promote.

Secrets management: Never store secrets in Git. Use Sealed Secrets or External Secrets Operator to sync from Vault or AWS Secrets Manager.

Branch-based environments: Create ArgoCD ApplicationSets that spin up preview environments for every pull request. Developers get a live URL to test before merging.

Monitoring the pipeline: Set up alerts for failed syncs in ArgoCD and failed CI runs in GitHub Actions. A pipeline that fails silently is worse than no pipeline at all.

The Result

With this setup, a developer's workflow becomes: write code, push, and walk away. Tests run automatically. Images build automatically. Deployments happen automatically. Rollbacks are a single command.

This is the same pipeline architecture we've implemented for fintech clients handling regulated deployments — achieving 15x faster deploy cycles with a 100% audit trail.

Need help setting up a Kubernetes CI/CD pipeline for your team? Get in touch — we'll design a pipeline tailored to your stack and compliance requirements.