February 22, 2026Every CI pipeline faces the same tension: run enough tests to catch bugs before they merge, but not so many that developers wait twenty minutes for feedback on a one-line change. The answer is not running everything everywhere. It is running the right tests at the right time.
Tests divide into three tiers based on execution speed, failure signal quality, and infrastructure requirements.
February 22, 2026Choosing the right mix of tests determines whether your test suite catches real bugs or just consumes CI minutes. There is no single correct answer – the right strategy depends on your system architecture, team size, deployment cadence, and the cost of production failures.
The classic testing pyramid, introduced by Mike Cohn, prescribes many unit tests at the base, fewer integration tests in the middle, and a small number of end-to-end tests at the top.
February 22, 2026Not every infrastructure change needs a full Kubernetes cluster to validate. Some changes can be verified with a linter in under a second. Others genuinely need a multi-node cluster with ingress, persistent volumes, and network policies. The cost of choosing wrong is real in both directions: too little validation lets broken configs reach production, while too much wastes minutes or hours on environments you did not need.
February 22, 2026A validation playbook is a structured procedure that tells an agent exactly how to validate a specific type of infrastructure change. The key problem it solves: the same validation (for example, “verify this Helm chart works”) requires different commands depending on whether the agent has access to kind, minikube, a cloud cluster, or nothing but a linter. A playbook encodes all path variants in one document so the agent picks the right commands for its environment.
February 21, 2026Operators are custom controllers that manage CRDs. They encode operational knowledge – the kind of tasks a human operator would perform – into software that runs inside the cluster. An operator watches for changes to its custom resources and reconciles the actual state to match the desired state, creating, updating, or deleting child resources as needed.
The Operator Framework defines five maturity levels:
| Level | Capability | Example |
|---|---|---|
| 1 | Basic install | Helm operator deploys the application |
| 2 | Seamless upgrades | Operator handles version migrations |
| 3 | Full lifecycle | Backup, restore, failure recovery |
| 4 | Deep insights | Exposes metrics, fires alerts, generates dashboards |
| 5 | Auto-pilot | Auto-scaling, auto-healing, auto-tuning without human input |
Most custom operators target Level 2-3. Levels 4-5 are typically reached by mature projects like the Prometheus Operator or Rook/Ceph.