An OCI region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents). The architecture uses a single region.

A logical grouping of DevOps resources needed to implement a CI/CD workflow. DevOps resources can be artifacts, build pipelines, deployment pipelines, external connections, triggers, and environments. DevOps projects make it easy to enable logging, monitoring, and notifications for all your DevOps resources.

A build pipeline takes a commit ID from your source code repositories and uses that source code to run your build instructions. Build pipelines defines a set of stages for the build process: building, testing and compiling software artifacts, delivering artifacts to OCI repositories, and optionally triggering a deployment. You define the flow and instructions of your build run in the build spec file.

Stages are individual actions that take place during a run of a pipeline. Various build stages mentioned here are:

• Managed Build Stages—A managed build stage to build and test the source code.
• Deliver Artifacts Stage—A stage to push the outputs of build stage to various repositories. Like container images to container repository and deployment manifest to artifact registry.
• Invoke Deployment—A stage to invoke a deployment pipeline once the build stages are completed ,along with parsing the exported variables from managed build stage to deployment pipeline stages.

Private Git repositories hosted by the DevOps service. You can store, manage, develop source code with our DevOps Code Repositories.

A sequence of steps for delivering and deploying a set of artifacts to a target environment. The flow and logic of your software release can be controlled by defining stages that can run in serial or parallel.

Stages are individual actions that take place during a run of a pipeline. In this we are using Compute Instance Group rolling stage with in deployment pipeline, which will install application to OCI Compute instances accordingly.

A DevOps artifact is a reference or pointer to any file, binary, package, manifest, or image that makes up your application. When creating an artifact, inform Oracle DevOps of the source location of the actual artifact. DevOps supports OCI Container Image Registry and OCI Artifact Registry repositories.

Artifact Repository creates repositories to group similar artifacts. When the repository is created, you can upload artifacts to it. These artifacts are a collection of text files, binaries, and deployment manifests that are delivered to the target deployment environment. Each artifact has a name, which is made of its path: version. The path is a string to organize the artifacts.

OCI Logging service stores logs related to the deployment. The deployment runtime output and the final results of the deployment are shown as log entries. OCI Notifications service provides visibility into the latest state of the deployment project and its resources and takes any necessary action. For example, you're notified when an important event, such as a stage in a deploy pipeline waiting for approval. When you receive the notification message, you can go to DevOps deployment pipelines and approve the stage.

An environment is a collection of a customer’s computing resources where artifacts are deployed. Environments can be a function, Compute virtual machine (VM) or bare metal instance, or an OKE cluster. The Blue Green deployment is available only with OKE cluster and Compute virtual machines.

Oracle Cloud Infrastructure provides fast, flexible, and affordable compute capacity to fit any workload need from performant bare metal servers and VMs to lightweight containers. OCI Compute provides uniquely flexible VM and bare metal instances for optimal price-performance. This architecture uses OCI Compute with Oracle Linux as OS image.

The Oracle Cloud Infrastructure Load Balancing service provides automated traffic distribution from one entry point to multiple servers reachable from your virtual cloud network (VCN). The service offers a load balancer with your choice of a public or private IP address, and provisioned bandwidth.

This architecture uses an Oracle Linux OS image with either E3 or E4 flex shape with minimum resources to host compute hosts in the OKE cluster nodes. If your application needs more memory or cores, you can choose a different shape.

When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.

After you create a VCN, you can change, add, and remove its CIDR blocks.

This architecture uses a public VCN to host Oracle Container Engine for Kubernetes. You can also use a private VCN. In that case, use a NAT gateway to give the cluster access over the public internet.

If you choose the architecture to deploy to an instance group, you have new Compute instances of your choice of shape created in your tenancy.

This architecture creates an artifact for the software and configuration used by an instance group, OKE, and Functions deployment. The architecture creates an artifact registry repository for internal use. Software binaries, text, and deployment configurations are uploaded to and downloaded from the artifact registry repository.