CI CD Pipelines for OKE

A cluster is only as useful as your ability to ship to it safely and repeatably. Manual deployments to OKE work for a demo and fail for a team, because they are slow, error prone and impossible to audit. A continuous integration and continuous delivery pipeline turns deployment into an automated, repeatable, reviewable process: code goes in one end and a running, tested workload comes out the other. This article lays out how to build that pipeline for OKE and where the decisions are.

It is part of our OKE and containers series and pairs with the deployment model in GitOps on OKE.

The shape of a pipeline

A CI CD pipeline for containers has a consistent shape regardless of the tools. Continuous integration builds the application into a container image, tests it and scans it. Continuous delivery takes that trusted image and deploys it to the cluster, usually progressing through environments. The clean separation between building an image once and deploying that same image everywhere is the heart of a good pipeline, because it means what you tested is exactly what runs.

Building and scanning images

The build stage compiles your application into a container image. Good practice is small, layered images built from trusted bases, tagged immutably so a given tag always refers to the same image. After the build, the image is scanned for known vulnerabilities, and a failed scan should stop the pipeline, not merely warn. Treating the scan as a gate rather than a notification is what keeps vulnerable images out of the cluster, which is the supply chain layer of the security model in OKE security best practices.

The registry as the handoff

Between continuous integration and continuous delivery sits the container registry. The pipeline pushes the built, tested, scanned image to the registry once, and every environment deploys that same image by its immutable reference. This is what guarantees that what runs in production is exactly what passed the tests, because nothing is rebuilt between environments. Using the OCI container registry keeps images close to the cluster and integrated with OCI identity and scanning.

Deploying to the cluster

The delivery stage applies the new image to the cluster, almost always through declarative Kubernetes manifests or Helm charts rather than imperative commands. A rolling update replaces pods gradually so the application stays available throughout, and readiness checks ensure traffic only goes to pods that are actually ready. For higher stakes deployments, blue green or canary strategies let you shift traffic gradually and roll back quickly if something is wrong, which is far safer than a single big switch.

Environment promotion

Mature pipelines move a change through environments in sequence, typically development, then a staging or pre production environment, then production. The same image is promoted through each, with environment specific configuration supplied separately rather than baked into the image. Each promotion can require its own approvals and gates, so production deployments are deliberate. This staged promotion is what turns a pipeline from a deployment script into a controlled delivery process.

Where GitOps fits

There are two broad models for the delivery half. In a push model, the pipeline reaches into the cluster and applies changes directly. In a pull model, known as GitOps, the desired cluster state lives in a Git repository and a controller inside the cluster continuously reconciles reality against it. GitOps gives you a clean audit trail, because the repository is the record of what should be running and why, and it makes drift visible and self correcting. Many mature estates use the pipeline to build and push, and GitOps to deploy, getting the best of both. The full treatment is in GitOps on OKE.

A pipeline framework

Securing the pipeline itself

The pipeline is a privileged path into your cluster, so it is a target. The credentials it uses to deploy should be least privilege and short lived, ideally backed by workload identity rather than long lived keys. The registry it pushes to and pulls from should be trusted and access controlled. And the pipeline's own configuration should be reviewed like code, because an attacker who controls the pipeline controls what runs. A pipeline that ships securely but is itself insecure simply moves the weak point.

Observability of deployments

You want to know not just that a deployment happened but whether it went well. Tying deployment events to your monitoring lets you see the effect of each release on error rates and latency, so a bad deployment is caught quickly and rolled back. This connects delivery to the observability practice in monitoring OKE with OCI tools, and a fast rollback path is itself part of safe delivery.

Bringing it together

A good CI CD pipeline for OKE builds an image once, tests and scans it, pushes it to a trusted registry, and deploys that exact image through environments with safe rollout strategies. Whether the final hop is a push from the pipeline or a pull via GitOps, the principles hold: one trusted artifact, declarative deployment, staged promotion and a fast way back. Get that in place and shipping to OKE becomes routine and safe rather than tense and manual. Continue with GitOps on OKE and OKE upgrade strategy.

The DevOps and IaC solution practice builds delivery pipelines for OKE estates on a fixed project fee.