OCI DevOps Service Pipelines

A pipeline is the automated path a change takes from a developer's commit to running in production, and it is where the safety of frequent change lives. The OCI DevOps service provides build and deployment pipelines native to OCI, so a team can keep its source, build its artifacts, and deploy them to OCI targets within one managed service rather than stitching together external tools. This guide explains how those pipelines work and how to design them so change reaches OCI both quickly and safely.

It is part of our DevOps and automation on OCI cluster, and it sits alongside our guides on Terraform on OCI and the OCI Resource Manager, which together cover the infrastructure side of the same operating model.

Two kinds of pipeline

The OCI DevOps service offers two complementary kinds of pipeline. A build pipeline takes source code and turns it into a deployable artifact: it pulls the code, compiles or assembles it, runs tests, and produces something ready to deploy, such as a container image or a package. A deployment pipeline takes that artifact and delivers it to the target environment, applying it consistently and in the right order across the stages that lead to production. Together they form the path from a commit to a running change.

Separating build from deployment is more than a technicality. It means an artifact is built once and then promoted unchanged through environments, so the thing tested in a lower environment is exactly the thing that reaches production, with no rebuild in between that could introduce a difference. Build once and promote is one of the foundational disciplines of safe delivery, and the two pipeline types are designed to support it.

What a build pipeline does

A build pipeline is a sequence of stages that transforms source into a deployable artifact. It begins by pulling the source from a repository, which can be OCI's own code repositories or an external source, and then runs the stages that build and verify the result. These typically include compiling or assembling the code, running automated tests, and packaging the output, with the option to fail the build if any stage does not pass so that a broken change never produces a deployable artifact.

The value of the build pipeline is consistency and verification. Every build runs the same stages in the same way, so the result does not depend on who triggered it or what was on their machine, and the tests in the build catch problems early, while they are cheap to fix, rather than late in production. A build pipeline that includes good tests is the first line of defence in safe delivery, and it is where many problems should be stopped.

What a deployment pipeline does

A deployment pipeline takes a verified artifact and delivers it to its targets, which on OCI can be compute instances, container environments such as OKE, functions, and other services. It moves the artifact through stages, often a path of lower environments before production, applying it the same way each time and pausing for approval where a human decision is needed. This staged, consistent delivery is what turns a deployment from a risky manual event into a routine, predictable operation.

Deployment pipelines also support safer release strategies. Rather than replacing everything at once, a pipeline can roll out a change gradually or alongside the existing version, so that a problem is caught before it affects everyone, an approach we cover in our wider material on safe deployment. The pipeline is where these strategies are encoded, so that every release follows the safe pattern rather than depending on someone remembering to do it carefully.

Approvals keep accountability human

Automation should handle the mechanical work of delivery, but the decision to release to production is often one that should rest with a person, and deployment pipelines support this through approval stages. An approval stage pauses the pipeline until an authorized person confirms the change should proceed, which keeps a human accountable for what reaches production while leaving everything around that decision automated. This balance, automated mechanics with human authorization at the right point, is what makes a pipeline both fast and governed.

Where approvals sit is a design decision worth thinking about. Too many approvals slow delivery to a crawl and train people to approve without looking; too few remove the accountability that approvals exist to provide. The right design puts an approval where a genuine decision is needed, usually before production, and lets the lower stages flow automatically so the pipeline stays fast where speed is safe.

Secrets and permissions

A pipeline that builds and deploys needs credentials, and how those credentials are handled decides whether the pipeline is secure. Secrets should never be embedded in pipeline definitions or source; they should be drawn from a secure store such as the OCI vault at the moment they are needed, so they are never exposed in code or logs. The pipeline itself should run with permissions scoped to exactly what it needs to do, so that a compromise of the pipeline cannot reach beyond its purpose.

This is part of treating the pipeline as a piece of production infrastructure that deserves the same security care as anything else, because a pipeline with broad permissions and exposed secrets is a powerful target. Designing the pipeline with least privilege and managed secrets from the start is far easier than retrofitting it later, and it keeps the automation that delivers change from becoming the weakest point in the estate's security.

Connecting infrastructure and application delivery

The DevOps service pipelines deliver application changes, and they work best alongside the infrastructure as code that delivers infrastructure changes, so that both flow through disciplined, automated paths. An estate where the application is deployed through pipelines but the infrastructure is changed by hand has only half the benefit, because the infrastructure remains a source of unreviewed, untested change. Bringing both under pipeline discipline, with Terraform or the Resource Manager handling infrastructure and the DevOps service handling application delivery, completes the picture.

How these pieces fit together depends on the estate, and there is no single correct arrangement, but the principle is constant: every change, whether to application or infrastructure, should flow through an automated path that tests and approves it before it lands. Designing that complete path is the heart of the work in our DevOps and IaC solution, and our OCI implementation service builds estates on these pipelines from the start. A team with well designed pipelines for both application and infrastructure can change its OCI estate frequently and confidently, which is exactly what the DevOps operating model is for.