OCI DevOps Pro flashcards
OCI DevOps Pro · Build recall with a focused review session.
33 cards. Read the term and the definition here. The deck at the top of this page is optional.
- DevOps project
- Top-level OCI DevOps container that groups pipelines, triggers, connections, and artifact repositories. IAM policies and notification topics are typically scoped at the project level.
- Build pipeline stage order
- Stages execute sequentially. Typical order: Managed Build, Deliver Artifact, then Trigger or Wait. A later stage does not start until the prior stage succeeds.
- Managed Build stage
- Runs a build spec YAML in an OCI-managed build runner. The stage references the spec file and the source repository/connection used to fetch code.
- Deliver Artifact stage
- Copies a build output into an OCI Artifact Registry repository as an artifact version. It substitutes a placeholder token in the artifact with the built file path.
- Build spec YAML
- Defines a build run: version, component, and steps. Each step has a type (Command or Shell), a name, and the command to execute in the runner.
- Deploy pipeline stage types
- Includes rolling deploy, blue-green (OKE), canary (OKE), load balancer traffic shift, wait, and approval. The stage selects the target environment for deployment.
- Deployment environment
- A reference to the deploy target: OKE cluster, compute instance group, Functions application, or load balancer. Deploy stages bind to one environment.
- DevOps connection
- Stores credentials for an external system such as GitHub, GitLab, Bitbucket Cloud, or VBS. Pipelines reference the connection instead of embedding secrets.
- DevOps trigger
- Fires a build pipeline automatically on repository events (push, pull request). Trigger types include GitHub, GitLab, Bitbucket Cloud, and VBS.
- Approval stage
- Pauses a deploy pipeline until a listed approver acts. Only users on the approver list can approve; the pipeline resumes on approval or fails on timeout.
- Blue-green on OKE
- Deploys a new ReplicaSet alongside the current one, verifies health, then shifts service traffic. The old version remains for rollback until promotion completes.
- Canary on OKE
- Sends a small percentage of traffic to the new version first, then promotes to full traffic after the canary passes. Reduces blast radius of a bad release.
- Rolling deploy on compute
- Updates instances in an instance group in batches according to a deployment policy (batch size, wait interval). Instances are replaced wave by wave.
- Artifact version immutability
- Artifact versions in OCI Artifact Registry cannot be overwritten. Reusing a version name fails, so builds should tag with commit SHA or build number.
- Private build runner
- A build runner placed in a VCN private endpoint. It can reach private resources such as a private OKE API endpoint or an internal artifact repository.
- DevOps IAM verbs
- Policies use manage, use, and inspect on resources like devops-projects, devops-pipelines, devops-build-runs, devops-deployments, and devops-connections. manage includes create and delete.
- Build run status values
- A build run reports Succeeded, Failed, Canceled, or In progress. Logs are retained per step, and the run history is visible in the project.
- Pipeline deletion order
- A project cannot be deleted while it contains active pipelines. Delete or deactivate dependent pipelines, then delete the project.
- DevOps notifications
- A project can publish pipeline events to an OCI Notifications topic. Subscribers receive build and deploy state changes via the topic.
- Deployment principal
- The identity that runs a deployment is the user who started the pipeline run. That user's IAM policies determine what the deployment can access.
- Build runner shape
- The compute size allocated to a managed build runner, such as small, medium, or large. Larger shapes give more CPU and memory for heavy builds.
- Build-minute billing
- Managed build runners are billed per build-minute of execution. Cost scales with runner size and total build duration.
- Artifact Registry repository
- Stores build artifacts and container images. DevOps deliver stages target a generic repository, and versions are referenced by pipelines.
- Wait stage
- A pipeline stage that pauses for a fixed duration before continuing. It is often used to let a canary soak before full promotion.
- Load balancer deploy stage
- Shifts traffic between backend sets on an OCI load balancer. Used to implement blue-green at the load balancer layer without a full OKE redeploy.
- Source repository reference
- A build stage points to a repository and branch through a connection. The trigger passes the commit reference to the build run.
- Build step command type
- A step type that runs a shell command in the runner. The other common type is Shell, which runs an inline script block.
- Deploy pipeline
- Ordered stages that deploy an artifact to an environment. It can include approval and wait stages between deploy stages.
- Rollback on OKE
- Blue-green keeps the previous ReplicaSet until promotion. If the new version fails health checks, traffic is not shifted and the old version keeps serving.
- Trigger event payload
- Repository event data passed to the build, including commit SHA and branch. Builds use it to tag artifact versions uniquely.
- DevOps logging integration
- Build and deploy logs are available in OCI Logging. Logs can be queried and retained according to the log group configuration.
- Environment per stage
- Each deploy stage chooses one environment. A pipeline can promote the same artifact across dev, staging, and prod by using multiple stages.
- Manual vs automatic trigger
- A manual trigger starts a build on demand. An automatic trigger starts it on repository events such as push or pull request.