This image shows the traffic flow for a canary deployment strategy. It is as follows:

1. Developers commit code to the OCI code repository, which passes it into the build pipeline.
2. Code goes through managed build stages and artifacts are delivered to the artifact repository and the container registry.
3. Code is then passed on to the Deployment Pipeline, which it traverses as follows:
   1. First it goes through the canary Oracle Container Engine for Kubernetes (OKE) deployment or canary instance group deployment process, which submits it for validation and also passes it on for deployment validation to the canary Namespace server in OKE are the VM Pool in the Oracle Instance Pool.
   2. After deployment validation, code is passed to the canary OKE traffic shift or the canary instance group traffic shift and then passed out of the deployment pipeline and on to OKE's NGINX controller or the Oracle Instance Pool's production load balancer.
   3. Within the Deployment Pipeline, the code is then referred to control approval.
   4. Once approved, it is passed to either the canary deploy instance group or OKE deploy production.
4. OKE's NGINX controller is also fed data from the OKE canary and OKE production namespace servers and passes this traffic to a production load balancer.
5. Traffic forwarded to the Oracle instance pool from the canary deploy instance group or OKE Deploy production process to the canary VM pool is run through a test load balancer or directly to the Oracle Instance Pool's production load balancer. Traffic also comes from the production VM pool an out to the production load balancer.

All activity in this process is managed by the Oracle Service Network components:

• Logging Service
• Monitoring Service
• Notification Service
• OCI Functions