Oracle Cloud Visual Builder Studio Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Application Development

Category

Application Development

1. Introduction

Oracle Visual Builder Studio is Oracle Cloud’s hosted development platform for planning, coding, building, and delivering applications—especially when teams need a managed DevOps-style environment closely aligned to Oracle’s application extension and cloud ecosystem.

In simple terms: Visual Builder Studio gives you a browser-based “engineering workspace” that typically includes source code repositories, work tracking, and CI/CD-style automation so a team can go from idea → code → build → deliver with less infrastructure to manage.

Technically, Visual Builder Studio is a managed Application Development service in Oracle Cloud that provides project-centric tooling (for example: Git repositories, issue tracking/Agile planning, build automation and delivery workflows—capabilities vary by subscription and configuration). It is usually provisioned as a service instance in a specific Oracle Cloud region, accessed securely over HTTPS, and governed through Oracle identity and access controls.

Problem it solves: teams often struggle with fragmented tooling (separate Git, separate ticketing, separate build servers, separate credentials) and the operational overhead of securing and running those tools. Visual Builder Studio consolidates common application lifecycle needs into a managed Oracle Cloud service and integrates cleanly with surrounding Oracle Cloud services and Oracle application extension workflows.

Naming note (important): Oracle previously offered Oracle Developer Cloud Service. Many organizations encounter it in older blogs or screenshots. Oracle positions Visual Builder Studio as the modern, actively used service for similar project + CI/CD capabilities. If you are migrating from older Developer Cloud Service workflows, verify current migration guidance in official documentation because UI and feature mappings can change.


2. What is Visual Builder Studio?

Official purpose (service intent): Visual Builder Studio is designed to help teams manage the application lifecycle—from planning and source control through automated builds and delivery—within Oracle Cloud, including common scenarios like extending Oracle Cloud Applications and building cloud-native services.

Core capabilities (high-level)

Visual Builder Studio commonly provides capabilities in these areas (exact availability can depend on your Oracle Cloud subscription, identity domain setup, and enabled features—verify in official docs for your tenancy):

  • Project workspace to organize application work (users, roles, components, environments)
  • Source control via hosted Git repositories
  • Work tracking such as issues/backlogs (Agile-style planning), and collaboration features
  • Automation such as build jobs/pipelines and delivery workflows
  • Integration points to connect with Oracle Cloud services used for deployment targets (for example OCI Container Registry, Kubernetes, Functions, Object Storage), and with external developer tools via webhooks/APIs

Major components (conceptual model)

Even if labels differ slightly in your console, Visual Builder Studio usage typically revolves around:

  • Visual Builder Studio instance: the provisioned service endpoint in your Oracle Cloud tenancy
  • Organization / Projects: a logical grouping for teams and applications
  • Repositories: hosted Git repos for code
  • Work items: issues/tasks/boards (naming varies)
  • Build automation: jobs or pipelines that run scripted steps (for example Maven builds)
  • Artifacts / build outputs: outputs produced by builds (where stored/retained depends on configuration)

Service type and scope

  • Service type: Managed cloud service (PaaS/SaaS-style) focused on Application Development and lifecycle tooling.
  • Scope: Typically instance-based in a specific OCI region and associated with a tenancy/compartment and identity domain. Users access it globally over HTTPS, while data residency follows the region where the instance is provisioned.
  • How it fits into Oracle Cloud ecosystem:
  • Identity & governance: integrates with Oracle identity (OCI IAM / Identity Domains) for authentication and authorization.
  • Deployment targets: commonly paired with OCI services such as Compute, Container Engine for Kubernetes (OKE), Container Registry (OCIR), Functions, API Gateway, Object Storage, and Vault (exact integrations vary—verify for your version/edition).
  • Application extension: frequently used in Oracle ecosystems to manage code and delivery for extensions to Oracle Cloud Applications (verify the recommended extension patterns for your Oracle application suite).

3. Why use Visual Builder Studio?

Business reasons

  • Faster delivery with fewer tools to stitch together: reduces “toolchain tax” by offering a consolidated environment for common development lifecycle tasks.
  • Standardization: a shared, governed platform improves consistency across teams (naming, branching, pipelines, approvals).
  • Lower operational overhead: less time spent maintaining self-managed Git servers, build servers, and plugins.

Technical reasons

  • Project-centric development: code, work items, builds, and releases can be tied to a single project context.
  • Automation-first workflows: scripted builds and repeatable delivery reduce “works on my machine” risk.
  • Oracle Cloud adjacency: easier integration into OCI networking, identity, and resource governance than running separate third-party tooling without tight integration.

Operational reasons

  • Managed service posture: platform availability, patching, and core operations are handled by Oracle (you still operate your pipelines, credentials, and target environments).
  • Auditability: centralized project activity and build logs simplify troubleshooting and governance (specific audit event depth can vary—verify).

Security/compliance reasons

  • Centralized access control: consistent user lifecycle and project permissions through Oracle identity.
  • Separation of concerns: projects can be separated by compartment, environment, and access model.
  • Better secrets discipline (when integrated properly): pipelines can reduce the spread of long-lived credentials (use OCI Vault or supported secret stores where available—verify).

Scalability/performance reasons

  • Elastic approach to builds (conceptually): rather than sizing and maintaining your own build farm, you rely on managed runners/executors or configured build infrastructure (implementation details vary—verify).
  • Repeatable build environments: defined templates or scripted environment setup reduce drift.

When teams should choose Visual Builder Studio

Choose Visual Builder Studio when you want: – A managed Oracle Cloud developer lifecycle platform – Strong alignment with Oracle Cloud Application extension workflows – A centralized place for Git + work tracking + build automation inside Oracle Cloud governance boundaries – Reduced need to operate third-party DevOps tooling

When teams should not choose it

Consider alternatives when: – You must use a single enterprise-standard platform like GitHub Enterprise Cloud or GitLab Ultimate across all clouds, and policy prohibits parallel tooling. – You require a feature that your Visual Builder Studio edition/region doesn’t provide (for example a specific compliance certification, runner type, or integration)—verify availability before committing. – You need full control of build infrastructure, plugins, and custom executors at a deep level (self-managed Jenkins/GitLab may fit better).


4. Where is Visual Builder Studio used?

Industries

  • Enterprises already invested in Oracle Cloud and Oracle applications (finance, manufacturing, retail, telecom, public sector)
  • Regulated industries where governance and identity integration are priorities (banking, healthcare)—subject to regional compliance and contractual terms (verify compliance documents)

Team types

  • Application development teams (Java, JavaScript, services)
  • DevOps/platform engineering teams standardizing CI/CD
  • Teams building extensions to Oracle Cloud Applications
  • Systems integrators delivering Oracle-based solutions

Workloads

  • Web applications and APIs
  • Integration services packaged with CI builds
  • Extension codebases and configuration managed as code
  • Microservices delivered to OCI targets (OKE/Functions/Compute)

Architectures

  • Monorepo or multi-repo setups with centralized project governance
  • Microservices with per-service build pipelines
  • Multi-environment promotion (dev → test → prod) using gated approvals
  • Hybrid setups where code lives in Visual Builder Studio but deployments reach both OCI and external environments (if supported via scripts/agents)

Real-world deployment contexts

  • Production delivery pipelines for apps running on OCI
  • Dev/test pipelines for validating changes and enforcing standards
  • Extension delivery where releases must align to Oracle application update cycles

5. Top Use Cases and Scenarios

Below are realistic scenarios where Visual Builder Studio fits well. Each includes the problem, why it fits, and a short example.

1) Managed Git + CI for OCI-hosted microservices

  • Problem: Teams need a governed Git and build system inside Oracle Cloud without managing servers.
  • Why it fits: Visual Builder Studio can host repos and automate builds tied to a project.
  • Example: A payments API team stores Java microservices in Visual Builder Studio repos and runs Maven builds on every pull request.

2) Oracle Cloud Applications extension delivery (project + pipeline)

  • Problem: Extension work needs controlled releases and traceability across tickets, code, builds, and deployments.
  • Why it fits: Project artifacts live together: issues → commits → builds → releases.
  • Example: A CRM team develops extension code, tracks requirements as work items, and uses builds to package deliverables.

3) Standardized build pipelines across teams

  • Problem: Each team uses different CI scripts and environments, leading to inconsistent quality.
  • Why it fits: Shared templates and project patterns help enforce consistency (where supported).
  • Example: Platform engineering provides a “standard Java build job” that all teams clone and customize minimally.

4) Controlled release promotion with approvals

  • Problem: Promotions from test to production need approvals and auditability.
  • Why it fits: Delivery workflows can be designed with gates and roles (capabilities vary—verify).
  • Example: A regulated team requires security sign-off before deploying to production OKE.

5) CI for UI projects (Oracle JET / JavaScript)

  • Problem: Front-end builds and linting are inconsistent across developer machines.
  • Why it fits: Central CI ensures consistent Node toolchain usage.
  • Example: A UI team runs npm ci, npm test, and bundle builds on every branch update.

6) Automated code quality checks (unit tests, static analysis)

  • Problem: Bugs reach later stages because tests aren’t enforced.
  • Why it fits: Build jobs can fail on test failures and surface logs centrally.
  • Example: A service team blocks merges unless unit tests pass and coverage meets a threshold (coverage gating support may vary—verify).

7) Multi-repository dependency orchestration

  • Problem: A product has many repos and needs orchestrated builds.
  • Why it fits: Pipelines can coordinate build steps and dependencies (depth varies—verify).
  • Example: Core library repo triggers downstream builds for services consuming it.

8) Secure developer onboarding for Oracle Cloud projects

  • Problem: New hires need fast, controlled access to repos and pipelines.
  • Why it fits: Central project membership and roles simplify onboarding.
  • Example: A new engineer gets access to the “Inventory” project and its repos, without receiving broad OCI permissions.

9) Integration with OCI deployment targets

  • Problem: Teams want pipeline-driven deployments to OCI services.
  • Why it fits: Visual Builder Studio can be used as the control plane for scripted deployment steps to OCI targets (verify supported integrations).
  • Example: A build produces a container image and deploys to OKE via a scripted step using OCI CLI and kubectl.

10) Audit-ready traceability from requirement to release

  • Problem: Auditors want traceability: what changed, who approved, what was deployed.
  • Why it fits: Project-centric artifacts connect work items, commits, builds, and releases.
  • Example: A healthcare app team exports release evidence for a quarterly audit.

6. Core Features

Feature availability and naming can differ by edition and tenancy configuration. Use this section as a practical checklist and verify specifics in official Visual Builder Studio documentation for your environment.

1) Visual Builder Studio instances (service provisioning)

  • What it does: Lets you provision an instance of the service in Oracle Cloud.
  • Why it matters: Establishes the governed endpoint where projects live.
  • Practical benefit: Centralizes tools and access in one managed service.
  • Caveats: Region choice affects data residency and latency; moving instances across regions is typically non-trivial (verify).

2) Project workspaces

  • What it does: Organizes code, work items, builds, and team roles by project.
  • Why it matters: Keeps multiple applications/teams separated with boundaries.
  • Practical benefit: Easier governance, reporting, and lifecycle management.
  • Caveats: Large organizations should define project taxonomy early to avoid sprawl.

3) Hosted Git repositories

  • What it does: Provides Git repo hosting within Visual Builder Studio.
  • Why it matters: Keeps source close to CI and project governance.
  • Practical benefit: Simplified permissions and onboarding.
  • Caveats: If you already have a mandated enterprise Git platform, duplication can be a concern; consider mirroring/integration patterns.

4) Branching and code review workflow (where available)

  • What it does: Supports collaborative workflows (feature branches, merge reviews).
  • Why it matters: Enforces review standards and reduces risk.
  • Practical benefit: Standard path for changes into protected branches.
  • Caveats: Exact capabilities (approvals, checks, protected branches) vary—verify.

5) Issue tracking / Agile planning (where available)

  • What it does: Tracks tasks/bugs/stories and team progress.
  • Why it matters: Connects planning with code and delivery.
  • Practical benefit: One place to manage delivery commitments.
  • Caveats: If your organization already standardizes on Jira/Azure Boards, you may use Visual Builder Studio primarily for repos/pipelines only.

6) Build automation (jobs/pipelines)

  • What it does: Runs automated build steps (for example: compile, test, package).
  • Why it matters: CI reduces regressions and speeds feedback loops.
  • Practical benefit: Standardized build environments and reproducible logs.
  • Caveats: Runner/executor types and concurrency limits are key—verify quotas and cost model.

7) Build triggers

  • What it does: Starts builds on events (commit, merge, schedule, manual).
  • Why it matters: Automates validation and reduces manual steps.
  • Practical benefit: Consistent enforcement of checks.
  • Caveats: Excessive triggers can cause cost and queue delays.

8) Artifacts and build outputs (retention/hosting depends on configuration)

  • What it does: Preserves outputs produced by builds (packages, reports).
  • Why it matters: Build outputs must be stored for release and traceability.
  • Practical benefit: Easy access to packaged deliverables.
  • Caveats: Artifact storage location and retention policy affect cost; some orgs store artifacts in OCI Object Storage or artifact registries—verify supported options.

9) Delivery / deployment automation (where available)

  • What it does: Coordinates releases into environments using pipeline stages.
  • Why it matters: Repeatable deployments reduce production risk.
  • Practical benefit: Promotion workflows with approvals and environment targeting.
  • Caveats: Deployment targets and native integrations vary—verify what’s supported vs. what must be scripted.

10) Integrations with OCI services (identity, storage, container, compute)

  • What it does: Enables pipelines to interact with OCI resources.
  • Why it matters: Most production apps need deployment targets, secrets, artifacts, and telemetry.
  • Practical benefit: Reduces glue code and credential sprawl when well integrated.
  • Caveats: Use least privilege policies and short-lived credentials where possible; do not embed keys in repos.

11) Notifications and webhooks (where available)

  • What it does: Notifies teams about builds/releases and integrates with external systems.
  • Why it matters: Faster incident response and visibility.
  • Practical benefit: Push events to chat, ITSM, or monitoring systems.
  • Caveats: Webhook endpoints must be protected; avoid leaking sensitive build metadata.

12) Access control and roles

  • What it does: Controls who can read/write code, run builds, administer projects.
  • Why it matters: Prevents unauthorized changes and enforces separation of duties.
  • Practical benefit: Cleaner compliance posture.
  • Caveats: Role design must align with your org’s SDLC; avoid granting admin broadly.

13) Auditability and logs (service + pipeline logs)

  • What it does: Provides logs for builds and project activity; instance-level actions may appear in OCI audit logs (verify).
  • Why it matters: Essential for troubleshooting and compliance evidence.
  • Practical benefit: Central trail of what happened and when.
  • Caveats: Log retention and export options must be planned.

7. Architecture and How It Works

High-level service architecture

At a conceptual level:

  1. You provision a Visual Builder Studio instance in an Oracle Cloud region.
  2. You create projects that include Git repos and (optionally) work items.
  3. Developers push code to Git.
  4. Builds run on a managed or configured build executor/runner.
  5. Build outputs are stored and/or published to downstream registries.
  6. Delivery workflows deploy to environments in OCI or elsewhere, often via scripted steps and service integrations.

Request/data/control flow (typical CI path)

  • Control flow: Developer action (commit/PR/merge) triggers a build.
  • Data flow: Source code pulled from Git → build runner executes steps → outputs published to artifacts store/registry → optional deploy pipeline pushes to runtime targets.
  • Feedback loop: Build results, logs, and status updates inform developers and release managers.

Integrations with related services (common patterns)

Depending on your architecture, Visual Builder Studio may integrate with:

  • Oracle Cloud Infrastructure Identity/IAM (Identity Domains): authentication and authorization
  • OCI Vault: store secrets such as tokens, API keys, or signing keys (verify supported mechanisms)
  • OCI Container Registry (OCIR): store container images
  • OCI Container Engine for Kubernetes (OKE): run workloads
  • OCI Compute: VM-based deployment targets
  • OCI Object Storage: artifact storage and build logs export (pattern-based; verify)
  • OCI Logging/Monitoring: observability for deployed workloads (build observability differs)

Dependency services

Your end-to-end delivery typically depends on: – An OCI tenancy with the correct identity setup – Network access (outbound internet or NAT) for builds that download dependencies – Target runtime services (OKE/Compute/Functions) if you deploy

Security/authentication model (practical view)

  • User auth: typically via Oracle identity (SSO/Identity Domains). Users are assigned to projects with roles.
  • Service-to-service auth: build/deploy steps typically use credentials you configure (API keys, tokens, or dynamic mechanisms). Prefer managed secret storage and least privilege.
  • Repository auth: via HTTPS credentials/personal tokens or SSH keys (options depend on configuration—verify).

Networking model

  • Visual Builder Studio is commonly accessed over public HTTPS.
  • Build runners need outbound network access to fetch dependencies and reach deployment targets.
  • If you require private connectivity patterns, validate support (for example private endpoints, allowlists, or private runners) in official docs—capabilities vary.

Monitoring/logging/governance

  • Build logs: primary signal for pipeline troubleshooting; set retention and export strategy.
  • Instance lifecycle: instance create/delete and configuration changes may be visible in OCI-level audit logs (verify).
  • Governance: use OCI compartments, tags, and naming conventions for instances and related resources.

Simple architecture diagram

flowchart LR
  Dev[Developer] -->|Git push| VBSRepo[Visual Builder Studio Git Repo]
  VBSRepo -->|Trigger build| Build[Build Job / Pipeline]
  Build --> Logs[Build Logs]
  Build --> Artifact[Build Output / Artifact]

Production-style architecture diagram

flowchart TB
  subgraph Users
    Dev1[Developers]
    RM[Release Manager]
  end

  subgraph OracleCloud[Oracle Cloud]
    subgraph VBS[Visual Builder Studio Instance]
      Proj[Project: repos + work items]
      Repo[Git Repositories]
      CI[Build Automation]
      CD[Delivery Automation]
    end

    subgraph SharedServices[Shared OCI Services]
      IAM[Identity / IAM]
      Vault[OCI Vault]
      OCIR[OCI Container Registry]
      Obj[Object Storage]
      Log[Logging / Monitoring]
    end

    subgraph Runtime[Runtime Targets]
      OKE[OKE Cluster]
      Compute[Compute Instances]
      Fn[OCI Functions]
      APIGW[API Gateway]
    end
  end

  Dev1 -->|SSO| IAM
  RM -->|SSO| IAM

  Dev1 -->|Commit/PR| Repo
  Repo --> CI
  CI -->|Fetch secrets| Vault
  CI -->|Push image/package| OCIR
  CI -->|Store artifacts| Obj

  CD -->|Deploy| OKE
  CD -->|Deploy| Compute
  CD -->|Deploy| Fn
  OKE --> APIGW

  Runtime --> Log
  CI --> Log

8. Prerequisites

Before starting, confirm these prerequisites for your Oracle Cloud environment.

Account/tenancy requirements

  • An Oracle Cloud (OCI) tenancy with permissions to provision Application Development services.
  • Access to create a Visual Builder Studio instance (or an existing instance you can use).

Permissions / IAM roles

You typically need: – Permissions to create and manage Visual Builder Studio instances in the target compartment. – Permissions to manage projects/users inside the Visual Builder Studio instance.

OCI IAM policy syntax and resource names can change and differ by service family naming. Do not guess policies in production. Use the official “Visual Builder Studio IAM policies” documentation for the exact policy statements for your tenancy.

Billing requirements

  • A paid OCI account or an entitlement/subscription that includes Visual Builder Studio.
  • If you run builds that allocate compute, store artifacts, or deploy to OCI targets, ensure billing is enabled for those services as well.

Tools needed (local workstation)

For the hands-on tutorial in this article: – Git client: – macOS: git (Xcode tools) – Windows: Git for Windows – Linux: distro package – A code editor (VS Code or similar) – Optional but useful: – Java 17+ and Maven (for local testing) – OCI CLI (only needed for optional deployment steps; not required for the core lab)

Region availability

  • Visual Builder Studio is provisioned per region. Availability can differ by region and by identity domain type.
  • Verify region availability for Visual Builder Studio in your OCI console and official service availability pages.

Quotas/limits

Common constraints to check: – Maximum number of instances per tenancy/compartment – Storage limits for repos/artifacts – Build runner concurrency and job time limits – User/project limits

Exact values are tenancy- and subscription-dependent—verify in official docs and your OCI quotas page.

Prerequisite services (optional)

If you plan to extend the lab into deployments: – OCI Container Registry (OCIR) – OKE, Compute, or Functions – OCI Vault – OCI Logging/Monitoring


9. Pricing / Cost

Visual Builder Studio pricing can be contract- and edition-dependent, and Oracle Cloud pricing can be governed by: – Universal Credits (pay-as-you-go consumption) – Subscription models tied to Oracle PaaS/SaaS entitlements – Included entitlements for specific Oracle application extension rights (common in Oracle Cloud Applications contexts)

Because Oracle’s pricing catalogs can differ by program and region, do not assume a single global price.

Pricing dimensions to expect (cost model patterns)

When estimating cost, consider these dimensions (verify which apply to your tenancy):

  1. Service entitlement / instance cost – Some environments treat Visual Builder Studio as an entitled service with a fixed subscription. – Others may have metered usage characteristics.

  2. Build execution cost – Even when the platform is managed, builds consume compute-like resources (runner time, concurrency). – If builds run on OCI compute in your tenancy or a managed pool, you may pay for underlying compute usage.

  3. Storage – Git repo storage – Artifact storage (either internal or in OCI Object Storage/registry) – Log retention storage if exported

  4. Network egress – Downloading dependencies usually incurs minimal cost, but egress to the public internet from OCI services can be chargeable depending on path and region. – Pulling/pushing large container images can increase costs.

  5. Downstream deployment targets – OKE worker nodes, load balancers, API Gateway, compute instances, databases, etc.

Free tier

Oracle Cloud has a Free Tier program, but Visual Builder Studio availability under Free Tier is not guaranteed and can change. Treat this as: verify in official pricing and Free Tier pages.

  • Oracle Cloud Free Tier overview: https://www.oracle.com/cloud/free/

Official pricing references (start here)

  • Oracle Cloud Pricing overview: https://www.oracle.com/cloud/price/
  • Oracle Cloud Cost Estimator: https://www.oracle.com/cloud/costestimator.html

For Visual Builder Studio-specific pricing/entitlement, use your Oracle contract documentation and the Visual Builder Studio product pricing page if listed for your program. If you cannot find a service-specific line item, that usually indicates the service is bundled/entitled or governed by a different SKU—confirm with Oracle sales/support.

Cost drivers (what usually moves the bill)

  • Number of active developers and projects (especially if user-based entitlements apply)
  • Build frequency (commits/day), build duration, parallelism
  • Artifact size and retention length
  • Container image storage and pulls
  • Production environment scale (OKE/Compute/DB)

Hidden or indirect costs to watch

  • Dependency downloads: repeated downloads can increase build time and potentially egress cost depending on network path.
  • Log retention: “keep logs forever” becomes expensive.
  • Parallel builds: high concurrency can drive compute usage.
  • Third-party integrations: licenses for scanners, SAST tools, etc.

How to optimize cost (practical controls)

  • Limit build triggers to meaningful branches (main/release + PRs).
  • Use dependency caching when supported (or store dependencies in a private registry close to runners).
  • Set artifact retention policies (keep only what you need).
  • Prefer smaller base images and smaller artifacts.
  • Separate CI (frequent) from CD (controlled promotion) to avoid unnecessary deployments.

Example low-cost starter estimate (no fabricated numbers)

A low-cost starter setup usually includes: – 1 Visual Builder Studio instance – 1 small project with 1–3 repos – A CI job running unit tests on commit with limited concurrency – Minimal artifact retention (days/weeks, not months/years)

The cost will largely depend on: – Whether the instance is bundled/entitled in your Oracle program – How build execution is billed in your environment – Any additional OCI services you enable

Action: Put your expected build minutes/hours and artifact storage into the Oracle Cost Estimator for the underlying OCI services you’ll use (Object Storage, OKE, etc.), and confirm Visual Builder Studio’s commercial model with your Oracle account team.

Example production cost considerations

In production, costs typically expand due to: – Multiple environments (dev/test/stage/prod) – Larger teams and more repositories – More frequent builds with parallel runners – Container registry storage + traffic – OKE node pools, load balancers, WAF, API Gateway – Central logging, metrics, and retention requirements


10. Step-by-Step Hands-On Tutorial

Objective

Provision a Visual Builder Studio instance in Oracle Cloud, create a project with a Git repository, push a simple Java/Maven application, and run an automated CI build that executes unit tests and packages the application.

This lab is designed to be: – Beginner-friendly – Low-risk (no production changes) – Cost-aware (minimal resources; cleanup included)

Lab Overview

You will: 1. Create or use an existing Visual Builder Studio instance 2. Create a project and Git repository 3. Push a sample Maven project to the repo 4. Create a build job/pipeline that runs mvn test package 5. Validate build results and logs 6. Clean up resources to avoid ongoing charges

Note: Visual Builder Studio UI labels can vary between releases and tenancy setups. When you see a slightly different label, use the nearest equivalent (Project Settings, Repositories, Builds, Pipelines). If you get stuck, use the official docs listed in the Resources section.


Step 1: Confirm access and create a Visual Builder Studio instance

  1. Sign in to the Oracle Cloud Console.
  2. Locate Visual Builder Studio under Application Development / Developer Services (exact navigation may vary).
  3. Create an instance: – Choose a compartment – Choose a region (data residency matters) – Provide an instance name
  4. Wait for the instance status to become Active/Ready.
  5. Open the instance URL (it typically opens the Visual Builder Studio web UI).

Expected outcome: You can access the Visual Builder Studio web UI and see the landing page where you can create or view projects.

Verification: – You can sign in successfully. – The instance shows as provisioned and reachable over HTTPS.

Common errors and fixes:You cannot create an instance: you likely lack IAM permission or quota. Verify OCI policies and quotas for this service in your compartment. – Instance creation fails: verify region availability and limits; check OCI error details.


Step 2: Create a project and a Git repository

  1. In Visual Builder Studio, create a new Project. – Name: vbs-maven-ci-lab – Description: “Maven CI lab” – Visibility: choose private/internal according to your org rules
  2. In the project, create a Git repository. – Repository name: hello-maven
  3. Capture the repository clone URL (HTTPS or SSH).

Expected outcome: A project exists and contains an empty Git repository.

Verification: – You can see the repository in the project’s Repositories section. – The UI provides a clone URL.


Step 3: Create a sample Maven app locally

On your workstation, create a minimal Maven project with a unit test.

  1. Create a working directory:
mkdir -p vbs-lab/hello-maven
cd vbs-lab/hello-maven
  1. Create this file structure:
mkdir -p src/main/java/com/example
mkdir -p src/test/java/com/example
  1. Create pom.xml:
<!-- pom.xml -->
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.example</groupId>
  <artifactId>hello-maven</artifactId>
  <version>1.0.0</version>

  <properties>
    <maven.compiler.release>17</maven.compiler.release>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <junit.jupiter.version>5.10.2</junit.jupiter.version>
  </properties>

  <dependencies>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter</artifactId>
      <version>${junit.jupiter.version}</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.2.5</version>
        <configuration>
          <useModulePath>false</useModulePath>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>
  1. Create the main class src/main/java/com/example/Calculator.java:
package com.example;

public class Calculator {
    public int add(int a, int b) {
        return a + b;
    }
}
  1. Create the test src/test/java/com/example/CalculatorTest.java:
package com.example;

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;

public class CalculatorTest {

    @Test
    void add_twoNumbers_returnsSum() {
        Calculator c = new Calculator();
        assertEquals(7, c.add(3, 4));
    }
}
  1. (Optional) Run locally:
mvn -B test package

Expected outcome: Maven runs tests and produces target/hello-maven-1.0.0.jar.

Verification:BUILD SUCCESStarget/ directory exists with build outputs.

Common errors and fixes:Wrong Java version: install Java 17+ or adjust maven.compiler.release. – Maven not installed: install Maven or skip local run and rely on the CI build.


Step 4: Push the code to the Visual Builder Studio Git repository

  1. Initialize Git and commit:
git init
git add .
git commit -m "Initial Maven app with unit test"
  1. Add the Visual Builder Studio repo as remote. – Copy the clone URL from the Visual Builder Studio repo page. – Then run (example):
git remote add origin <PASTE_YOUR_VBS_GIT_REMOTE_URL_HERE>
git branch -M main
git push -u origin main

If prompted for credentials, use the authentication method configured by your organization (HTTPS credentials/token or SSH key). Verify the recommended approach in your Visual Builder Studio documentation.

Expected outcome: Your repository in Visual Builder Studio now contains pom.xml and the source files.

Verification: – In the web UI, browse the repository and confirm files are present.

Common errors and fixes:Authentication failed: confirm you are using the correct credentials/token, or configure SSH keys if required. – Push rejected due to branch rules: push to an allowed branch or adjust repository rules (admin required).


Step 5: Create a CI build job/pipeline that runs Maven

In your Visual Builder Studio project, create a build definition. UI terms vary (Build Job, Pipeline, Job Configuration). The goal is the same: check out code and run Maven commands.

  1. Navigate to the project’s Builds / CI area.
  2. Create a new build job/pipeline: – Source repository: hello-maven – Branch: main
  3. Add a build step that runs:
mvn -B test package

If there is a Maven-specific step, use it and set goals to test package. If not, use a generic “Shell” step.

  1. Configure triggers: – Start with manual trigger for this lab. – Later you can enable “on commit” triggers for CI.

  2. Save the build configuration.

Expected outcome: A build job exists and is ready to run against main.

Verification: – You can see the build job listed in the project. – The job is associated with your repository and branch.

Common errors and fixes:Build environment lacks Java/Maven: choose a build VM template/executor that includes a suitable JDK and Maven, or add steps to install them (slower). The available templates depend on your tenancy—verify. – Repo checkout fails: confirm repository permissions and that the pipeline can access the repo.


Step 6: Run the build and review logs

  1. Start the build manually (“Run Build”, “Start”, or similar).
  2. Watch the build console output.

What you should see: – Checkout stage – Maven downloading dependencies – JUnit test execution – BUILD SUCCESS

Expected outcome: Build completes successfully, tests pass, and the package step runs.

Verification checklist: – Build status: Success – Logs show the test add_twoNumbers_returnsSum executed – Logs show the jar built under target/

If artifact publishing is configured in your environment, you may also see an artifact tab or downloadable output. If not, logs are still sufficient for CI validation.

Common errors and fixes:Dependency downloads time out: verify outbound network access from build runners, proxy settings, or retry with fewer parallel downloads. – Tests fail: open the test report/log and fix code, then push a new commit and rerun.


Validation

Use this checklist to confirm the lab worked:

  • [ ] Visual Builder Studio instance is reachable and you can sign in
  • [ ] Project vbs-maven-ci-lab exists
  • [ ] Repo hello-maven contains code on main
  • [ ] Build job runs and ends with Success
  • [ ] Build logs show Maven tests and package succeeded

Troubleshooting

Problem: “Permission denied” when creating a project or repo – Cause: you are not a project admin or lack organization permissions. – Fix: request the correct role assignment in Visual Builder Studio, or have an admin create the project.

Problem: Git push fails due to authentication – Cause: wrong credential method (token vs password) or missing SSH key. – Fix: use the credential method your org enables. Many modern configurations require tokens rather than passwords. Verify in official docs.

Problem: Build queue never starts – Cause: no available build executors/runners, quota reached, or executor misconfiguration. – Fix: check build executor status, concurrency limits, and quotas; reduce parallel builds.

Problem: Maven uses an unexpected Java version – Cause: build template provides a different JDK. – Fix: select a template with the correct JDK, or configure JAVA_HOME per build runner documentation (verify).


Cleanup

To avoid ongoing cost and reduce clutter:

  1. In Visual Builder Studio: – Delete the build job/pipeline (optional) – Delete the project vbs-maven-ci-lab (recommended for a lab)
  2. In the Oracle Cloud Console: – Delete the Visual Builder Studio instance if you no longer need it

Expected outcome: Resources are removed and you are no longer billed for related consumption.


11. Best Practices

Architecture best practices

  • Separate CI and CD concerns: CI validates and packages; CD promotes to environments with approvals.
  • Standardize pipeline templates: provide blessed build steps for Java/Node, and require teams to extend them.
  • Design for traceability: connect work items → commits → builds → releases.

IAM/security best practices

  • Least privilege everywhere: developers should not need broad OCI admin rights just to commit code.
  • Separate duties: restrict who can edit pipelines that deploy to production.
  • Use short-lived credentials and secret stores: do not store API keys in repos; prefer OCI Vault (or supported secret features).

Cost best practices

  • Tune triggers: avoid building every branch unless needed.
  • Right-size retention: store only essential artifacts and logs.
  • Control concurrency: set maximum parallel jobs to prevent accidental cost spikes.

Performance best practices

  • Cache dependencies where supported (or use a closer artifact repository).
  • Pin tool versions: keep Maven/Node versions consistent across developers and CI.
  • Fail fast: run unit tests early; do heavyweight packaging/scans later.

Reliability best practices

  • Idempotent deployments: rerunning a deployment should be safe.
  • Use environment-specific configuration: never hardcode endpoints.
  • Have rollback strategy: versioned artifacts and release tags enable rollback.

Operations best practices

  • Define ownership: who maintains build templates, runners, and org policies.
  • Monitor pipeline health: track failure rates and mean time to repair.
  • Document runbooks: common pipeline failures and how to fix them.

Governance/tagging/naming best practices

  • Use consistent naming:
  • Instance: vbs-<org>-<region>-<env>
  • Project: <product>-<service>-<env>
  • Repos: <service>-api, <service>-ui
  • Use OCI tags on the instance and downstream resources for:
  • Cost center
  • Owner/team
  • Environment (dev/test/prod)

12. Security Considerations

Identity and access model

  • Visual Builder Studio is typically integrated with Oracle identity (OCI IAM / Identity Domains).
  • Control access at two levels: 1. OCI level: who can create/manage instances 2. Studio level: who can access projects, repos, pipelines

Recommendation: keep OCI instance admin privileges limited to platform admins; grant developers access inside Visual Builder Studio projects instead.

Encryption

  • Data in transit is typically over HTTPS/TLS.
  • Data at rest encryption is expected in Oracle-managed services, but implementation details and customer-managed key options can vary—verify your service’s encryption and key management options in official docs.

Network exposure

  • Plan for internet-facing access by default (HTTPS).
  • If you need restrictions (IP allowlists, private access patterns, or private build runners), confirm availability and implement them carefully—verify in official docs.

Secrets handling

Common mistakes: – Embedding OCI API keys or tokens in repos – Copying secrets into pipeline logs – Using long-lived credentials without rotation

Secure recommendations: – Use OCI Vault for secrets where supported. – Mask secrets in build logs. – Rotate credentials and prefer scoped tokens with minimal permissions.

Audit/logging

  • Keep build logs long enough to support incident response and compliance needs.
  • Export evidence for regulated release processes (build logs, approvals, commit hashes).
  • Verify what actions are captured in OCI Audit vs. studio-level audit.

Compliance considerations

  • Confirm regional data residency needs before choosing a region.
  • Validate required certifications (ISO/SOC/etc.) via Oracle Cloud compliance documentation for your region and program—do not assume.

13. Limitations and Gotchas

Because Visual Builder Studio is a managed service, some constraints are expected:

  • Region-bound instances: your instance lives in a chosen region; moving may require migration steps.
  • Quota and concurrency limits: builds may queue during peak usage.
  • Runner environment variability: available build templates/executors differ by tenancy and release.
  • Integration depth varies: some integrations are native; others require scripted CLI/API calls.
  • Artifact handling differs: not every setup provides a first-class artifact repository; you may need OCIR/Object Storage.
  • Governance complexity: you must align OCI policies with studio project permissions.
  • Pricing surprises: costs often come from build execution, artifact storage, and downstream services rather than the UI layer itself.
  • Migration challenges: migrating from older Oracle Developer Cloud Service or from GitHub/GitLab requires careful mapping of repos, pipeline definitions, secrets, and permissions—verify official migration guidance.

14. Comparison with Alternatives

Visual Builder Studio sits at the intersection of Application Development tooling and DevOps automation in Oracle Cloud. Here’s how it compares.

Comparison table

Option Best For Strengths Weaknesses When to Choose
Oracle Visual Builder Studio Teams building on Oracle Cloud and/or extending Oracle Cloud Applications Integrated project + repo + automation in Oracle ecosystem; centralized governance Feature set and pricing/entitlement can vary; not always the enterprise standard outside Oracle-centric orgs You want a managed Oracle Cloud-native lifecycle platform
OCI DevOps (Oracle Cloud) OCI-native CI/CD for deploying to OCI resources Strong alignment to OCI resources and IAM; service-managed workflows Different scope and UI model than Visual Builder Studio; may require combining with external Git/boards You mainly need OCI CI/CD and deployments
Oracle APEX (Oracle Cloud) Low-code database-centric apps Very fast app delivery; tight Oracle DB integration Different problem space (app building) vs lifecycle tooling You need rapid low-code apps more than DevOps pipelines
GitHub (Actions) Broad developer ecosystem and integrations Massive ecosystem; familiar workflows Governance and data residency may require extra controls; not Oracle-native Your org standardizes on GitHub and needs ecosystem integrations
GitLab (CI/CD) Single platform for repo + CI/CD + security scanning Strong end-to-end DevSecOps capabilities Self-managed adds ops burden; SaaS may have governance constraints You want a unified DevSecOps platform with deep customization
Azure DevOps Enterprises standardized on Microsoft tooling Boards + repos + pipelines in one suite Cloud/provider mismatch for OCI-heavy orgs; cross-cloud complexity You are already standardized on Microsoft ALM
Jenkins (self-managed) Maximum CI/CD customization Extremely flexible and extensible Operational and security burden; plugin sprawl You need full control and can operate it securely at scale

15. Real-World Example

Enterprise example: Extending Oracle Cloud Applications with governed CI/CD

  • Problem: A large enterprise runs Oracle Cloud Applications and needs a governed way to deliver extensions with traceability, approvals, and repeatable packaging.
  • Proposed architecture:
  • Visual Builder Studio instance per major business unit or per environment boundary
  • Projects per application domain (HR, Finance, Supply Chain)
  • Git repos for extension code and configuration-as-code
  • CI builds run unit tests and package deliverables
  • CD pipelines deploy to controlled environments, with approvals from release managers
  • OCI Vault stores deployment credentials; logs exported for audit evidence
  • Why Visual Builder Studio was chosen: it fits the Oracle Cloud ecosystem and supports project-centric traceability while reducing operational overhead of running separate ALM tools.
  • Expected outcomes:
  • Faster, more reliable releases
  • Clear audit trail from requirements to deployment
  • Reduced toolchain fragmentation

Startup / small-team example: One place for repos + builds on OCI

  • Problem: A small team building an OCI-hosted SaaS wants managed repos and CI without standing up Jenkins.
  • Proposed architecture:
  • One Visual Builder Studio instance
  • A project with repos for API and frontend
  • CI builds on every merge to main
  • Artifacts stored in OCIR/Object Storage (depending on packaging)
  • Deployments to a small OKE cluster or Compute instances
  • Why Visual Builder Studio was chosen: fast setup, managed security posture, and easy integration with OCI governance.
  • Expected outcomes:
  • Consistent builds and test enforcement
  • Reduced operational load
  • Better onboarding and collaboration

16. FAQ

1) Is Visual Builder Studio the same as Oracle Visual Builder?
No. They are related but not identical. Visual Builder is primarily a low-code app development platform. Visual Builder Studio is focused on the broader application lifecycle (projects, repos, build/delivery automation). Some subscriptions may bundle experiences—verify in official docs for your edition.

2) Is Visual Builder Studio replacing Oracle Developer Cloud Service?
Oracle Developer Cloud Service appears in older materials. Visual Builder Studio is widely positioned as the modern service for similar lifecycle use cases. For migrations, verify Oracle’s current guidance.

3) Is Visual Builder Studio regional or global?
The instance is typically provisioned in a specific OCI region (data residency). Access is over HTTPS from anywhere, subject to identity and policy controls.

4) Do I need OCI CLI to use Visual Builder Studio?
No for basic repo + build usage. You might need OCI CLI for scripted deployments to OCI resources.

5) Can Visual Builder Studio deploy to OKE / Compute / Functions?
It can often be used to automate deployments via supported integrations or scripted steps. The exact “native” deployment features depend on your configuration—verify supported deployment targets.

6) How do developers authenticate to Git repositories?
Commonly via HTTPS credentials/tokens or SSH keys, depending on your organization’s settings. Use your tenant’s documented approach.

7) How do I implement least privilege for pipelines?
Use project roles to limit who can change pipelines, and use narrowly scoped OCI policies for the service identity/credentials used during deployment.

8) Where should I store secrets used by build and deployment steps?
Prefer a managed secrets solution like OCI Vault where supported, and ensure secrets are masked in logs. Avoid committing secrets to Git.

9) Can I connect Visual Builder Studio to GitHub or mirror repositories?
Integrations vary. Some teams use Visual Builder Studio as the primary Git host; others mirror from a central GitHub/GitLab. Verify supported integration patterns in official docs.

10) Does Visual Builder Studio include issue tracking?
Many editions include work tracking features, but capabilities can differ. If your organization already uses Jira, you can still use Visual Builder Studio mainly for repos and automation.

11) How do I control costs?
Control build frequency, artifact retention, and concurrency. Most cost growth comes from build execution and downstream OCI runtime services, not from creating a small project.

12) What’s the biggest operational gotcha?
Unmanaged pipeline sprawl and long-lived credentials embedded in scripts. Treat pipelines as production code with reviews, least privilege, and secret hygiene.

13) Can I enforce branch protections and required builds?
Many platforms support this, but exact options differ—verify branch policy and merge requirements available in your Visual Builder Studio.

14) How do I migrate existing Jenkins pipelines?
Start by porting build scripts first (Maven/Gradle/npm commands), then map credentials to Vault/secret storage, then reproduce triggers and approvals. Validate with a non-production project first.

15) Is there a certification specifically for Visual Builder Studio?
As of this writing, Oracle certifications are usually broader (OCI DevOps, OCI Developer, etc.). Verify current Oracle certification catalogs for the latest options.


17. Top Online Resources to Learn Visual Builder Studio

Links can change over time; if a specific page redirects, use the Oracle Help Center search for “Visual Builder Studio”.

Resource Type Name Why It Is Useful
Official documentation Oracle Help Center (Visual Builder Studio docs) – https://docs.oracle.com/ Canonical product documentation hub; search “Visual Builder Studio” for the latest admin and user guides
Official documentation Oracle Cloud Infrastructure Documentation – https://docs.oracle.com/en-us/iaas/ Useful for IAM, networking, Vault, OKE, OCIR integration patterns used by pipelines
Official pricing Oracle Cloud Pricing – https://www.oracle.com/cloud/price/ Baseline pricing references; confirm your program (Universal Credits vs subscription)
Pricing calculator Oracle Cloud Cost Estimator – https://www.oracle.com/cloud/costestimator.html Estimate downstream OCI service costs (compute, storage, OKE, etc.)
Free tier overview Oracle Cloud Free Tier – https://www.oracle.com/cloud/free/ Check whether your intended lab components are eligible
Architecture center Oracle Cloud Architecture Center – https://www.oracle.com/cloud/architecture/ Reference architectures for CI/CD, microservices, OKE, observability
Official samples Oracle Samples on GitHub – https://github.com/oracle-samples Practical sample apps and OCI patterns to use as pipeline inputs
Official videos Oracle YouTube channel – https://www.youtube.com/user/Oracle Search for Visual Builder Studio and OCI DevOps walkthroughs
Tutorials/labs Oracle LiveLabs – https://livelabs.oracle.com/ Hands-on labs for OCI developer services and deployment targets (availability varies)
Release updates Oracle Cloud “What’s New” – https://docs.oracle.com/en-us/iaas/releasenotes/ Track platform changes that might affect builds, identity, and integration behavior

18. Training and Certification Providers

The following institutes are listed as training providers. Availability, course outlines, and modes can change—check each website directly.

Institute Suitable Audience Likely Learning Focus Mode Website URL
DevOpsSchool.com DevOps engineers, developers, platform teams DevOps foundations, CI/CD concepts, tooling practices applicable to Oracle Cloud pipelines Check website https://www.devopsschool.com/
ScmGalaxy.com Beginners to intermediate DevOps learners SCM, CI/CD basics, DevOps process and labs Check website https://www.scmgalaxy.com/
CLoudOpsNow.in Cloud ops and DevOps practitioners Cloud operations practices and automation approaches Check website https://www.cloudopsnow.in/
SreSchool.com SREs, operations, reliability engineers SRE practices, reliability, observability for services deployed from CI/CD Check website https://www.sreschool.com/
AiOpsSchool.com Ops teams exploring AIOps Monitoring, automation, AIOps concepts (useful for operating deployed workloads) Check website https://www.aiopsschool.com/

19. Top Trainers

These sites are provided as training resources/platforms. Verify course relevance to Oracle Cloud and Visual Builder Studio specifically.

Platform/Site Likely Specialization Suitable Audience Website URL
RajeshKumar.xyz DevOps/cloud training content (verify current catalog) Beginners to intermediate engineers https://rajeshkumar.xyz/
devopstrainer.in DevOps training (CI/CD, automation) DevOps engineers and developers https://www.devopstrainer.in/
devopsfreelancer.com Freelance DevOps guidance and services (treat as platform unless verified) Teams needing hands-on help or mentoring https://www.devopsfreelancer.com/
devopssupport.in DevOps support/training resources Ops/DevOps teams https://www.devopssupport.in/

20. Top Consulting Companies

Presented neutrally as consulting/service providers. Validate capabilities, references, and Oracle Cloud experience during procurement.

Company Likely Service Area Where They May Help Consulting Use Case Examples Website URL
cotocus.com Cloud/DevOps services (verify offerings) CI/CD implementation, cloud migration support Designing pipeline standards, implementing secure secret handling, integrating with OCI targets https://cotocus.com/
DevOpsSchool.com DevOps consulting and training Toolchain design, CI/CD rollout, enablement Rolling out standardized build pipelines, DevSecOps practices, workshops for teams https://www.devopsschool.com/
DEVOPSCONSULTING.IN DevOps consulting (verify offerings) Automation, delivery pipelines, operational readiness CI/CD adoption, build optimization, environment promotion design https://devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Visual Builder Studio

  • Git fundamentals (branches, merges, pull requests)
  • CI basics (build/test/package)
  • Maven/Gradle or npm basics (depending on your stack)
  • OCI fundamentals:
  • Tenancy, compartments, policies
  • Networking basics (VCN, subnets, outbound access)
  • OCI Vault basics (secrets)

What to learn after Visual Builder Studio

  • OCI deployment targets:
  • OKE (Kubernetes) for containerized workloads
  • OCIR for images
  • API Gateway for API front doors
  • Observability (Logging, Monitoring)
  • DevSecOps:
  • Dependency scanning
  • SAST/DAST concepts
  • SBOM generation and artifact signing (tooling-dependent)
  • Release engineering:
  • Progressive delivery strategies
  • Rollback/roll-forward practices

Job roles that use it

  • Cloud application developer (Oracle Cloud)
  • DevOps engineer / CI/CD engineer
  • Platform engineer
  • SRE (as a consumer of release pipelines and build evidence)
  • Solution architect (designing delivery and governance)

Certification path (if available)

There may not be a Visual Builder Studio-specific certification. Consider: – OCI developer and DevOps certifications (if aligned with your role). Verify current certification offerings at Oracle’s official certification site: – https://education.oracle.com/

Project ideas for practice

  • Build + test + package a Java service with reproducible versioning (Git tags → build version).
  • Create a multi-repo pipeline that builds a shared library then downstream services.
  • Add security checks (dependency scan) and fail builds on high-severity findings.
  • Deploy a containerized app to OKE using a gated promotion pipeline (dev → stage → prod).

22. Glossary

  • OCI (Oracle Cloud Infrastructure): Oracle’s cloud platform providing compute, networking, storage, and managed services.
  • Tenancy: Your top-level OCI account/container for resources, policies, and billing.
  • Compartment: A logical grouping of OCI resources for access control and organization.
  • Identity Domain: Oracle identity boundary used for users, groups, and authentication (varies by setup).
  • Visual Builder Studio instance: The provisioned service endpoint where projects and repos live.
  • Project: A workspace grouping repos, work items, and automation.
  • Git repository: Version control repository storing source code and history.
  • CI (Continuous Integration): Automatically building and testing code changes frequently.
  • CD (Continuous Delivery/Deployment): Automating releases/promotions into environments.
  • Build runner / executor: The environment that runs build steps (VM/container/managed runner depending on service setup).
  • Artifact: A build output (jar, zip, container image) used for releases/deployments.
  • OCIR: Oracle Cloud Infrastructure Registry for container images.
  • OKE: Oracle Container Engine for Kubernetes, a managed Kubernetes service.
  • OCI Vault: Managed service for secrets and keys.
  • Least privilege: Security principle of granting only the minimum permissions required.

23. Summary

Visual Builder Studio in Oracle Cloud is an Application Development service that provides a managed, project-centric environment for source control, collaboration, and build/delivery automation—particularly valuable for teams building on OCI or delivering extensions aligned with Oracle ecosystems.

It matters because it helps teams standardize workflows, reduce toolchain overhead, and improve traceability from code to release. Cost is usually driven less by “having a project” and more by build execution, artifact/log retention, and downstream OCI deployment targets. Security success depends on least privilege, disciplined secrets handling, and clear separation of duties for production deployments.

Use Visual Builder Studio when you want a managed Oracle Cloud-native lifecycle platform; consider alternatives when your organization is already standardized on another DevOps suite or requires deep self-managed customization.

Next learning step: extend the lab by publishing build outputs to OCIR/Object Storage and deploying to an OCI runtime target (OKE/Compute/Functions), using OCI Vault-backed secrets and gated promotions for production.