CI/CD 🤖

A good pipeline is one you don't think about. It runs on every commit, catches problems before they reach production, and deploys with confidence. Everything below is what it takes to get there.

Build

The first step is converting application code into executable artifacts:

  1. Static analysis first. Tie checkstyle and static analysis to your build task so non-compliant code fails fast. For Java/Kotlin, I recommend Spotless and PMD.
  2. Dependencies. Your project pulls from your company's artifact repository (Artifactory/Nexus) with caching, your company provides pipeline templates handling cache logic, or your team implements caching in its own pipeline.
  3. Compile and package source code into binaries.

Testing

  • Run unit and integration tests to validate functionality on every pipeline run.
  • The closer your project is to production, the more your focus shifts to broader test coverage — see Types Of Testing.

Containerization

Your org may already have optimized base images. If not, a few non-negotiable practices:

  • Minimal base images — Amazon Corretto or Distroless to reduce attack surface.
  • Non-root execution — Switch to a non-root user after installation. Never run containers as root.
  • Multistage builds — Use builder patterns for smaller final images (buildx).
  • Vulnerability scanning — Scan images before deployment (e.g. Harbor, Trivy).
  • Image signing — Leverage Docker content trust for immutable, signed images.
  • TLS hardening — For JVM images, narrow down the list of allowed SSL ciphers and TLS versions.

Deployment

Infrastructure

Before deploying the app, your pipeline can provision application infrastructure using an IaC tool. This is especially valuable for generating dashboards, alerts, or any resource tied to the target environment.

Application

Two deployment models:

  • Push model — A CLI tool in your pipeline (or part of your templates) deploys the container directly.
  • Pull model (recommended) — A GitOps tool like Argo CD or Flux watches for changes and deploys from Git as the source of truth.

The pull model is preferable because it makes the desired state declarative, auditable, and recoverable. If something goes wrong, the Git history tells you what changed and when.

Measuring your pipeline

  • DORA Metrics — Pipeline KPIs fully captured from system usage (deployment frequency, lead time, change failure rate, MTTR).
  • SPACE Metrics — KPIs at System, Team, and Individual levels — only some are captured from system usage, others require surveys and self-reporting.