CI/CD: keep it simple

The new argument in software delivery is not that CI/CD matters. That fight ended years ago. The argument is about how much machinery a team should pile on top of it. Right now, the advice getting traction is almost stubbornly simple: keep the path from a git commit to a Docker image to a Kubernetes deployment as short and legible as possible. Even vendors selling bigger platforms now teach that basic shape as the default workflow, because it is easier to reason about and easier to recover when something breaks (developer.harness.io, argoproj.github.io). That sounds obvious until you remember what many CI/CD systems became. Over time, teams stacked on custom scripts, branching rules, environment-specific exceptions, approval gates, and deployment logic that only one or two people fully understood. The pipeline stopped being a conveyor belt and turned into a maze. DORA’s current framework for software delivery performance is built around outcomes like lead time, deployment frequency, failure rate, recovery time, and rework rate. Those metrics are a reminder that the point of delivery tooling is not elegance. It is moving changes safely without creating more cleanup work later (dora.dev, cloud.google.com). That is why the “simple pipeline” pitch has landed. A stripped-down flow makes each handoff visible. Code changes live in Git. Build artifacts become immutable container images. Deployment state is declared for Kubernetes and reconciled by a delivery tool instead of by a human with shell access. Argo CD, one of the most widely used GitOps tools in this stack, describes the goal in almost plain English: application definitions and configurations should be declarative, version controlled, automated, auditable, and easy to understand (argoproj.github.io). The important word there is not “automated.” It is “understand.” That same logic shows up in the fine print of the tooling. Argo CD’s own best-practices guide recommends separating application source code from deployment configuration so teams can change manifests without triggering unnecessary builds, keep a cleaner audit trail, and avoid accidental feedback loops in automation. It also warns against mutable dependencies in deployment manifests, because a pipeline is not predictable if the same Git revision can mean something different tomorrow than it meant today (argo-cd.readthedocs.io). Simplicity here does not mean primitive. It means fewer hidden state changes. The viral claim that simpler pipelines cut manual errors by about 60 percent is harder to pin down. I could not verify a primary source for that exact number. What the better evidence does show is the broader mechanism behind the claim. DORA’s 2024 research, based on more than 39,000 professionals, says platform engineering works when it reduces cognitive load and abstracts away underlying complexity for developers. When the platform is good, teams perform better. When the platform is bad, it just adds another layer to learn (dora.dev, dora.dev). That is the real shift. The industry spent years treating maturity as a synonym for more knobs, more stages, and more policy engines. Now the smarter version of maturity looks narrower. Give developers one paved route that works. Make it boring. Make it observable. Make the artifact immutable. Pin the deployment config. Let Kubernetes do the reconciliation. If a team needs a diagram to explain how code reaches production, the pipeline is already too complicated for the job it is supposed to do (cloud.google.com, argo-cd.readthedocs.io).