OCI DevOps Pro key terms

A logical container in OCI DevOps that groups source repositories, build pipelines, deployment pipelines, artifacts, and environments so teams can manage release work for one application as a unit.

A Git repository hosted by OCI DevOps that stores source code and can trigger build pipelines automatically when commits are pushed to a configured branch.

A stored link from OCI DevOps to an outside system such as GitHub, GitLab, Bitbucket, or Vault, holding credentials or tokens so pipelines can read code or secrets without embedding them.

An ordered set of build stages that OCI DevOps runs on managed or private build runners, typically compiling code, running tests, and producing artifacts that later stages or deployments consume.

One step inside a build pipeline, defined by a stage type such as managed build, deliver artifact, or trigger deployment, executed in sequence according to the pipeline definition.

A build stage where OCI provisions the compute to run the build specification, removing the need for customers to maintain their own build hosts or agents.

The compute size selected for a managed build, controlling CPU, memory, and cost; larger shapes shorten heavy builds while small shapes suit quick lint or unit-test jobs.

A YAML file, conventionally build_spec.yaml, that declares the steps, shell commands, environment variables, and output artifacts a build stage executes on its runner.

Customer-managed compute registered with OCI DevOps that runs build jobs inside a private network, useful when builds must reach internal dependencies or on-premises systems.

The compute environment, either OCI-managed or privately hosted, where build stages execute their commands and produce artifacts for downstream delivery.

A versioned output of a build, such as a container image or a binary file, stored in OCI Artifact Registry or Object Storage and referenced by deployment stages.

A build pipeline stage that uploads or publishes the artifact produced by earlier stages to its configured artifact repository so deployments can retrieve that exact version.

A build pipeline stage that starts a deployment pipeline run automatically when a build succeeds, connecting continuous integration to continuous delivery.

A rule that starts a pipeline automatically, for example on a push to a repository branch, a pull request event, or a schedule, optionally filtered by file paths.

An ordered collection of deployment stages that promotes a released artifact through environments such as test and production, with approval gates and rollback behavior between stages.

One step in a deployment pipeline that performs a deployment type such as rolling, blue-green, canary, or a shell script against a defined environment.

The method a deployment stage uses to replace running workloads, such as rolling replacement, blue-green switchover, canary traffic shifting, or a custom scripted procedure.

A strategy that replaces instances in batches while the rest keep serving traffic, keeping capacity available but briefly mixing old and new versions.

A strategy that runs a new version alongside the old one and switches traffic over once the new environment passes checks, allowing fast rollback by switching back.

A strategy that sends a small share of traffic to the new version first, monitors it, then gradually increases the share or aborts if error signals rise.

A named deployment target in OCI DevOps that binds a workload type, such as OKE or Compute, to the cluster or instances where releases are installed.

A deployment pipeline stage that pauses execution until designated approvers act, gating promotion to sensitive environments like production.

Returning a workload to its previous known-good release after a failed or unhealthy deployment, restoring the prior artifact version and configuration.

The specific artifact version, such as a container image digest or object, that a deployment stage installs into an environment during a pipeline run.

An OCI Artifact Registry container or generic repository that stores build outputs, supports immutable version tags, and serves images to OKE clusters during deployment.

A packaged, layered filesystem and metadata bundle stored in a registry and used to start containers; OCI DevOps typically delivers images to OKE during deployments.

A deployment environment whose target is an Oracle Container Engine for Kubernetes cluster, where stages apply Kubernetes manifests or Helm releases to namespaces.

A deployment environment backed by OCI compute instances or instance groups, where stages run scripts or install artifacts on those hosts.

The YAML that defines how a deployment executes, including strategy, rollout percentages, and the commands or manifests applied during the stage.

A single execution instance of a build or deployment pipeline, recording status, stage progress, logs, and the artifact versions involved for auditing.

A credential or configuration value stored in OCI Vault and referenced by pipelines at run time, keeping sensitive data out of source code and build specifications.

An OCI policy statement granting identities permission to manage DevOps resources or to let pipelines read artifacts, secrets, and clusters in specific compartments.

A configured rule that publishes events about pipeline runs, such as start, success, or failure, to OCI Notifications topics for alerting and audit visibility.

The practice of inspecting proposed changes in a pull request before merge, using comments, required reviewers, and status checks to catch defects early.

A request to merge a branch into another, showing the diff and discussion; in OCI DevOps it can be linked to triggers that run validation builds before merge.

Repository rules that block direct pushes to important branches and require reviews or passing builds before changes can merge, protecting release quality.

The practice of merging small changes frequently and automatically building and testing each one so integration problems surface quickly rather than at release time.

Keeping software in a releasable state by automating build, test, and deployment steps, with a manual or automated decision to promote each release to production.

Managing infrastructure through versioned definition files, such as Terraform or OCI Resource Manager stacks, so environments are reproducible and changes are reviewed like code.