4.3 OCI DevOps: Code Repositories, Build Pipelines & Deployment Strategies

Why CI/CD Is on the Architect Exam

The cloud-native objective explicitly mentions "DevOps practices" with OKE, Container Instances, and the OCI DevOps service. An architect is expected to design a pipeline that builds, tests, scans, and releases services safely, with the ability to roll back quickly. OCI DevOps provides this as a managed service, so you do not maintain Jenkins servers or build agents.

DevOps Building Blocks

Build Pipelines

A managed build stage runs on Oracle-managed build runners. Its instructions live in a build_spec.yaml file in the repository, which defines steps, environment variables, exported variables, and output artifacts. A typical build pipeline has these stages:

1. Managed build: compile, run unit tests, and build the container image.
2. Deliver artifacts: push the image to OCIR and upload other outputs, such as manifests, to Artifact Registry.
3. Trigger deployment: start the deployment pipeline with the new artifact versions.

The build pipeline runs with its own resource principal. You put build pipelines in a dynamic group and grant that group the access it needs, for example manage repos for OCIR and read secret-family to fetch credentials from Vault. Secrets are referenced from Vault in the build specification rather than stored in the repository.

Artifact Registry

Artifact Registry stores generic artifacts, such as JAR files, ZIP packages, or configuration bundles, in repositories. When you create a repository you can choose to make its artifacts immutable, so a published version cannot be overwritten. Container images belong in OCIR, not Artifact Registry.

Deployment Pipelines and Stages

A deployment pipeline is a graph of stages. Common stage types include:

• Deploy to OKE using Kubernetes manifests, or deploy a Helm chart to OKE.
• Deploy to an instance group of compute instances (rolling deployment).
• Deploy to Functions by updating a function to a new image.
• Invoke function to run custom checks.
• Wait for a set time.
• Manual approval, which pauses the release until an approver responds.
• Shell stage for custom commands.
• Strategy-specific stages: blue-green deployment and traffic shift, and canary deployment, canary traffic shift, and canary approval.

Deployment Strategies

Rolling Deployment

A rolling deployment updates instances or pods in batches. It needs no extra capacity, but old and new versions run side by side during the rollout, so the API and database schema must stay backward compatible. Rolling back means rolling out the previous version again.

Blue-Green Deployment

Two complete environments exist: blue (current production) and green (new release).

• For instance groups, DevOps deploys the new version to the green instances and then shifts traffic on the load balancer from the blue backends to the green backends.
• For OKE, you create two Kubernetes namespaces for the blue and green environments (the namespaces are selected in the stage, not written into the manifests), and an NGINX ingress controller routes traffic. The traffic shift stage switches the ingress so users reach the new namespace.

Rollback is fast: rerun the traffic shift stage manually to send traffic back to the untouched blue environment (blue-green pipelines do not support full pipeline redeployment). The tradeoff is running double capacity during the release window.

Canary Deployment

A small share of traffic goes to the new version first:

1. Canary deployment stage deploys the new version to a canary environment. For OKE this requires an NGINX ingress controller to route traffic; for instance groups you select a load balancer.
2. Canary traffic shift stage moves a defined percentage of traffic to the canary, optionally in several rounds.
3. Canary approval stage lets a person confirm that metrics and logs look healthy.
4. The production stage releases the new version everywhere.

You can enable automatic rollback to the last successful version if the production stage fails. Canary limits the blast radius of a bad release to a small group of users.

Putting Security Into the Pipeline

A secure pipeline combines several services covered elsewhere in this guide: vulnerability scanning of images in OCIR, image signing with Vault keys and image verification on OKE, Vault secrets for credentials, manual approval stages for production, and Logging of every pipeline run for audit purposes.