Embracing Deployment Agility: Canary and Blue-Green Deployments with OCI DevOps and Terraform
This guide explores OCI DevOps canary deployments with Terraform, showing how to gradually roll out changes in OKE clusters with safer, controlled releases. Modern cloud deployments can’t afford downtime. Whether you’re rolling out a new feature or upgrading your application backend, you need a strategy that minimizes risk while keeping users happy. That’s where canary and blue-green deployments come in.
Instead of pushing changes to 100% of users at once, these patterns let you shift traffic gradually, monitor the impact, and roll back instantly if something goes wrong. In OCI, you can codify the whole flow with DevOps service + Terraform. With OCI DevOps canary deployments, you can minimize risk by gradually shifting traffic in OKE clusters while keeping deployments automated with Terraform.
Architecture Overview
This architecture combines OCI DevOps pipelines, OKE clusters, and Terraform automation to deliver a safer rollout strategy.
GitHub integration: Source code is mirrored into OCI DevOps repositories, and every
git pushtriggers a new build.Build pipeline: OCI DevOps Build creates Kubernetes artifacts (manifests, images) and stores them in the Artifact Registry.
Deploy pipeline: A multi-stage pipeline handles Canary deployment first, then gradually shifts traffic to production using NGINX ingress.
Rollback and approvals: At each stage, OCI DevOps enforces gates (like manual approvals) and policies to ensure you can stop or roll back instantly.
This pattern allows teams to adopt modern deployment practices without leaving the OCI ecosystem, codified entirely in Terraform for repeatability.
By leveraging OCI DevOps Canary pipelines, teams can codify gradual rollouts directly in Terraform, ensuring automation and repeatability across environments.
This example demonstrates how OCI DevOps Canary deployments integrate with OKE clusters, making it easy to test real workloads while ensuring traffic is shifted in a safe, controlled manner.
Figure 1. Canary pipeline with OCI DevOps, OKE, and Terraform.Â
Defining the OCI DevOps Deploy Pipeline
At the core, you’ll need a DevOps deploy pipeline that orchestrates all the stages:
resource "oci_devops_deploy_pipeline" "FoggyKitchenDevOpsProjectDeployPipeline" {
project_id = oci_devops_project.FoggyKitchenDevOpsProject.id
display_name = "FoggyKitchenDevOpsProjectDeployPipeline"
deploy_pipeline_parameters {
items {
name = "namespace"
default_value = "foggykitchen"
description = "foggykitchenapp"
}
}
}
This sets up a reusable pipeline with parameters you can pass downstream (like namespaces or artifact versions).
OCI DevOps Canary Deployment Stage
The real magic happens in the canary stage. With Terraform, it looks like this:
resource "oci_devops_deploy_stage" "FoggyKitchenCanaryStage" {
deploy_pipeline_id = oci_devops_deploy_pipeline.FoggyKitchenDevOpsProjectDeployPipeline.id
deploy_stage_type = "OKE_CANARY_DEPLOYMENT"
display_name = "Canary Deployment Stage"
kubernetes_manifest_deploy_artifact_ids = [
oci_devops_deploy_artifact.FoggyKitchenManifestArtifact.id,
]
oke_cluster_deploy_environment_id = oci_devops_deploy_environment.FoggyKitchenOKEEnvironment[0].id
canary_strategy {
ingress_name = "foggykitchen-oke-canary-app-ing"
namespace = var.deploy_stage_canary_namespace
strategy_type = "NGINX_CANARY_STRATEGY"
}
}
👉 Here, the traffic is routed through NGINX ingress, targeting the canary namespace before touching production.
Traffic Shifting & Approval
Once the canary pods are live, you can shift traffic in batches and require human approval before a full rollout:
resource "oci_devops_deploy_stage" "FoggyKitchenTrafficShiftStage" {
deploy_pipeline_id = oci_devops_deploy_pipeline.FoggyKitchenDevOpsProjectDeployPipeline.id
deploy_stage_type = "OKE_CANARY_TRAFFIC_SHIFT"
rollout_policy {
batch_count = 1
batch_delay_in_seconds = 60
ramp_limit_percent = var.percentage_canary_shift
}
}
This is where safety meets automation — OCI DevOps handles the traffic, you just define the policy.
Why This Matters
Canary and blue-green strategies aren’t just buzzwords—they solve real problems in production. Instead of risking a big-bang release, these patterns let you test safely, measure impact, and recover instantly if things go wrong.
And the benefits go beyond safety:
âś… Reduced risk: only a fraction of users see the new version first.
âś… Controlled rollout: shift traffic gradually with rollback on errors.
âś… Built-in governance: approvals, logging, and notifications are part of the pipeline.
âś… Terraform powered: your deployment strategy is versioned and repeatable.
Wrapping Up
Canary and blue-green deployments are no longer reserved for hyperscale players — you can implement them today with OCI DevOps + OKE + Terraform. Mastering OCI DevOps Canary not only improves deployment safety but also prepares your pipelines for advanced strategies like blue-green and multi-cluster rollouts.
👉 Want the full pipeline code, including approval stages and rollback policies?
It’s available in my GitHub repo and explained in detail in the FoggyKitchen DevOps course: 🔗 OCI DevOps Service with Terraform (2023 Edition)
💡 Pro tip: treat this as a foundation. Once you’re confident with canary, layering blue-green deployments in OCI DevOps is just one step further.
🚀 Take Your OCI DevOps Skills Further
Go beyond the basics with hands-on labs covering the entire pipeline: from creating an OCI DevOps project, mirroring GitHub repos, and building pipelines — to advanced strategies like Canary and Blue-Green deployments. Each lesson includes step-by-step guidance, real Terraform/OpenTofu code, and practical scenarios you can apply immediately.
🔒 Lifetime • ⏱️ Self-paced • 🧪 Real labs
Check also other courses:​
How to automate Oracle Cloud Infrastructure with Terraform/OpenTofu (2025 Edition)
