OCI DevOps Service: Pipelines From Commit to Deploy

Every cloud platform eventually grows a delivery story, because the alternative is watching customers bolt third party CI/CD onto the side of the tenancy and wondering why deployments fail in ways the platform cannot see. The OCI DevOps service is Oracle's answer: a managed, integrated chain that takes source code, builds it, stores the resulting artifacts, and pushes them onto OCI compute targets with real deployment strategies, approval gates, and rollback behaviour. It is not trying to out feature GitHub or Jenkins. It is trying to be the path of least resistance for teams whose workloads already live on Oracle Cloud Infrastructure, and judged on those terms it does the job well.

This article is the delivery pipeline chapter of our wider series on application development and serverless on OCI. We will cover each component of the service in turn, compare the deployment targets and the strategies each one supports, explain how approvals and rollbacks actually behave, look at the cost model, and finish with the seven step framework we use to take a team from an empty project to gated production deploys.

What the service actually is

OCI DevOps is four capabilities under one roof. First, code repositories: private Git hosting inside your tenancy, with the option to mirror from external providers. Second, build pipelines: managed build runners that execute the steps you declare in a build spec file, with no Jenkins controller or runner fleet to patch. Third, artifact delivery: a stage type that pushes build outputs into the OCI Registry for container images or into Artifact Registry for everything else. Fourth, deployment pipelines: orchestrated rollouts to OKE clusters, Functions applications, and compute instance groups, with rolling, blue green, and canary strategies, manual approval stages, and structured rollback.

Everything lives inside a project, which is the unit of organization. A project belongs to a compartment, owns its repositories, pipelines, triggers, and environment references, and carries one mandatory attachment that surprises people on day one: a Notifications topic. The service requires the topic at project creation precisely so that pipeline events have somewhere to go, and in practice that default is a gift, because pipeline failures that nobody hears about are how broken builds sit unnoticed for a week. We typically map one project per application or per closely related set of services, not one project per environment; environments are modelled inside the deployment pipeline instead, a point we return to under common mistakes.

Code repositories and mirroring

The hosted repositories are standard Git. You clone over HTTPS with an auth token or over SSH, push branches, and browse commits and diffs in the console. They are deliberately lean: there is no issue tracker, no wiki, and only basic pull request support, because Oracle is not competing for your collaboration workflow. What the hosted repositories give you is locality. The code sits in your tenancy, in your region, governed by your IAM policies and audit logs, and the build runners reach it without any traffic leaving Oracle's network.

Most teams we work with keep their collaboration on GitHub, GitLab, or Bitbucket and use mirroring instead. You create an external connection backed by a personal access token stored in OCI Vault, point it at the upstream repository, and the service maintains a synchronized copy inside the project on a schedule measured in minutes. The mirror is read only from the OCI side, which is exactly what you want: developers keep their existing review workflow, and OCI DevOps sees every merged commit shortly after it lands. Triggers fire from the mirror just as they would from a native repository, so the developer experience upstream does not change at all.

Build pipelines and the build spec

A build pipeline is a sequence of stages, and the workhorse stage is the managed build. You select a runner shape, x86 or Arm, sized by OCPU and memory, and the service provisions an ephemeral Oracle Linux environment for the duration of the run. There is no standing fleet, no runner registration, and no operating system to patch. When the run finishes, the environment is gone.

What the runner executes is declared in a build spec file, a YAML file conventionally named build_spec.yaml at the root of the repository. The spec declares environment variables, references to Vault secrets through a vaultVariables block, an ordered list of steps containing the shell commands to run, and a set of named output artifacts that later stages can pick up. Keeping the spec in the repository rather than in console configuration means your build logic is versioned, reviewed, and reproducible, which is the entire point of pipeline as code. Pipelines also accept parameters, named values with defaults that you can override per run and reference inside stages with placeholder syntax. Parameters are how one pipeline definition builds feature branches, tags images with the commit hash, and varies behaviour between runs without anyone editing the pipeline itself.

Beyond the managed build stage, a pipeline can fan out stages in parallel, wait on a manual approval, trigger another pipeline, and deliver artifacts. That last one is the bridge to everything downstream.

Delivering artifacts

The deliver artifacts stage takes the outputs your build spec named and pushes them to a registry. Container images go to the OCI Registry, OCIR, which is the same registry that OKE, Functions, and OCI Container Instances all pull from, so an image built by the pipeline is immediately deployable by any container runtime in the tenancy. Everything that is not a container image, Helm charts, Kubernetes manifests, deployment configuration files, generic binaries, goes to Artifact Registry, which versions them and lets deployment pipelines reference a specific artifact version rather than whatever happens to be latest. The discipline that matters here is immutable tagging: tag images with the commit hash or a build number, never deploy a floating tag, and the artifact trail from any running workload back to its source commit stays unbroken.

Deployment pipelines and targets

Deployment pipelines are where OCI DevOps earns its keep, because this is the part that generic CI tools do badly on OCI without significant scripting. A deployment pipeline references environments, which are pointers to real infrastructure: an OKE cluster, a Functions application, or a compute instance group. The pipeline then rolls artifacts onto those environments using a declared strategy.

For OKE the pipeline can apply raw manifests or Helm charts, and the blue green and canary strategies are implemented with separate namespaces and an ingress level traffic shift. For instance groups, the closest thing OCI has to classic virtual machine fleets, the service executes your deployment script across the group in batches whose size you control. Functions deployments are simpler by nature, a function is a single image reference, so the pipeline updates it and then validates, a pattern we cover from the function side in our OCI Functions deep dive. Note what is absent from the table: Container Instances are not a native deployment target, so teams running there script the update with the CLI inside a build stage instead.

Strategies, approvals, and rollbacks

Rolling, blue green, and canary

Rolling replaces the running release in place, batch by batch, and is the right default for stateless services that tolerate brief version mixing. Blue green stands up the new release alongside the old one, validates it, then shifts traffic in one move, buying instant rollback at the price of double capacity during the window. Canary sends a small percentage of traffic to the new release first, holds while you watch error rates and latency, then proceeds to full rollout only when the numbers and the humans agree. The canary hold is where approval stages shine: the pipeline pauses at a defined traffic percentage and waits for a named person or group to approve continuation.

How approvals and rollbacks behave

An approval stage halts the pipeline and notifies the project topic. Designated approvers, controlled through IAM, approve or reject in the console, and every decision is recorded with identity and timestamp, which is the audit evidence change management teams actually ask for. Rollback is similarly structured: a failed stage can trigger automated rollback to the previous successful deployment, and for blue green that means shifting traffic back to the still running old environment in seconds. The discipline the platform cannot supply is that rollback only works if the previous artifact versions still exist and the deployment was strategy driven in the first place, which is one more argument against deploying by hand between pipeline runs.

Triggers: connecting commits to pipelines

Triggers close the loop between source and build. A trigger watches a code repository, native or mirrored, and fires a build pipeline when a matching event occurs: a push to a named branch, a pull request opened or updated against a target branch, or a merge completing. Filters on branch names and file paths keep monorepos sane, so a change under one service directory builds only that service. The standard wiring we install is two triggers per repository: pull request events run a validation pipeline that builds and tests but delivers nothing, and pushes to the main branch run the full pipeline that builds, delivers artifacts, and hands off to deployment. Developers get fast feedback on proposals, and only merged code ever produces a deployable artifact.

Integration with the rest of OCI

The strongest argument for OCI DevOps is how little glue it needs. Secrets used during builds, registry credentials, signing keys, API tokens, live in OCI Vault and are referenced from the build spec, arriving in the runner as variables that never appear in the repository or the logs. The pipelines themselves authenticate to other OCI services with resource principals, so there are no service account keys to create, rotate, or leak; you grant the DevOps dynamic group exactly the permissions the pipeline needs and nothing more. Pipeline lifecycle events flow to the Notifications topic, which fans out to email, Slack via a function, or PagerDuty. Build and deployment logs land in the Logging service, searchable alongside the application logs of the workloads being deployed, which makes the eternal question of whether an incident correlates with a deployment answerable in one query.

OCI DevOps or GitHub Actions or Jenkins

Honest answer: most teams arrive with CI/CD already in place, and ripping out a working delivery system to adopt the platform native one is rarely worth it. GitHub Actions has a vastly larger ecosystem of reusable actions and is the natural choice when the code, the reviews, and the team already live on GitHub; it deploys to OCI perfectly well with OIDC federation and the OCI CLI, and we walk that exact setup end to end in our GitHub Actions to OKE pipeline guide. Jenkins earns its place where heavyweight legacy build jobs and deep plugin investments exist, at the cost of running and patching the controller yourself. OCI DevOps wins in three situations: when you want zero CI/CD infrastructure to operate, when deployment strategy support for OKE and instance groups matters more than ecosystem breadth, and when compliance demands that source, build, artifacts, approvals, and audit logs all sit inside one cloud boundary under one IAM model. Plenty of estates land on a hybrid: GitHub for source and pull requests, mirrored into an OCI DevOps project that owns build and deployment.

What it costs

The service itself is effectively free. There is no charge for projects, repositories, pipelines, triggers, deployment orchestration, or approval stages. What you pay for is the compute the managed build runners consume while a build is executing, billed at ordinary OCI compute rates for the shape and duration, plus the normal storage costs of OCIR and Artifact Registry and a Notifications volume that rounds to nothing. A team running a few hundred moderate builds a month typically sees a bill in the tens of dollars, which compares very favourably with hosted CI pricing per seat or per build minute. The flip side is that slow builds are now directly metered, so a bloated Docker build that takes twenty minutes costs real money on every run; caching layers and trimming test suites pays back immediately.

Common mistakes

Three failures account for most of what we find in delivery reviews. First, secrets pasted into build specs or pipeline parameters. The spec lives in Git, parameters appear in run history, and either way the credential is now visible to everyone with read access; Vault references exist precisely so this never happens. Second, no approval gate in front of production. A pipeline that flows from merge to production without a pause is a policy decision someone should have made consciously, and in regulated environments it is an audit finding waiting to be written. Third, one pipeline serving every environment through ad hoc parameter switching. Development, staging, and production deserve distinct deployment pipelines with distinct environments, approvers, and rollback behaviour, even when they share the same build pipeline; collapsing them saves an hour of setup and costs a production incident later.

From empty project to gated production deploys

This is the sequence we follow in engagements, and it works whether the source of truth is a native repository or a GitHub mirror.

Bringing it together

OCI DevOps will not replace the richness of the GitHub ecosystem and is not trying to. What it offers is a complete, operations free delivery chain that speaks OCI natively: repositories and mirrors beside the workloads, ephemeral build runners you never patch, artifact registries the deploy targets already trust, and deployment pipelines that give OKE and instance groups real strategies, approvals, and rollbacks out of the box, all for roughly the cost of the build minutes you consume. For teams consolidating onto Oracle Cloud Infrastructure, that is a serious default. Designing the pipeline architecture, the IAM boundaries, and the promotion model across environments is exactly what our DevOps and infrastructure as code practice does, and our OCI implementation service builds the landing zone those pipelines deploy into.