Extend VBCS Code in Visual Builder Studio and Deploy It Through the Pipeline

Navigation

Steps

1. 1

   Open the App in a Workspace

   Which app, and how you get to it, depends on which of the two things you're doing. Building/editing a standalone VBCS app: sign in to Visual Builder Studio, select your Workspace (or your organization's default one), open its Applications list, and click the app by name to open it in the designer. Extending an existing Fusion Redwood page instead: you don't browse to it in VB Studio at all — you launch it from the live Fusion page itself (its Settings/user menu → "Edit Page in Visual Builder Studio"), which opens VB Studio already scoped to that page's extension, inside the workspace tied to your active sandbox. Either way, you land in a Workspace backed by its own Git repository — edit there, not against a live environment directly.

2. 2

   Create or Switch to a Feature Branch

   Isolate the change in Git before editing, so the mainline stays stable if the change needs rework — the workspace's Git integration branches the same way any Git repo does.

3. 3

   Make the Change in the Page Designer

   Edit the page, business object, or action chain in the visual designer (or the underlying page/action-chain JSON and JS directly). For a Fusion Redwood page extension specifically, this is the same designer opened via 'Edit Page in Visual Builder Studio' from the page's user menu, scoped to the extension layer on top of Oracle's own page.

4. 4

   Test Locally in the Workspace

   Preview and run the app inside the workspace before committing, to catch obvious breakage early.

5. 5

   Commit and Push to Git

   Commit the change (page/business-object JSON, action chain JS) and push it to the branch — this is what the Build stage actually builds from. A Build can only include what's been committed and pushed.

6. 6

   Merge to the Mainline Branch

   Merge the feature branch back once reviewed, since a Build is normally created from the branch an environment is configured to track — commonly the mainline branch.

7. 7

   Create a Build

   From the Environments page, trigger a Build from the latest commit. This packages the app into a deployable artifact that isn't yet tied to any one target environment.

8. 8

   Deploy the Build to Dev

   Deploy that artifact to the Dev environment and verify the change behaves as expected against Dev's data and connections.

9. 9

   Promote Dev to Test

   Promote — not rebuild — the same tested artifact to the Test environment, so what gets validated in Test is exactly what ran in Dev, not a fresh build from source.

10. 10

    Validate in Test

    Run functional/regression testing against Test. For a Fusion Redwood page extension, this typically means testing behind Test's own sandbox before it's published there too.

11. 11

    Promote Test to Production

    Once Test sign-off is complete, promote the same artifact to Production — this is normally gated behind an explicit approval/promote action rather than happening automatically on a schedule.

12. 12

    Confirm and Monitor in Production

    Verify the change is live and check the Environments/deployment history for errors before considering the migration complete. For a page extension, this also means publishing/activating the corresponding sandbox in Production — a separate step from the VB Studio deployment itself.

What Happens Technically?

Feature Branch → Commit & Push → Merge to Mainline → Build → Deploy to Dev → Promote to Test → Promote to Prod

Common Errors

• Build fails or is missing the expected change because local edits weren't committed and pushed first — a Build only ever includes what's in Git.
• Promotion is blocked because the target environment isn't registered, or its Git branch tracking doesn't match what was actually built.
• The change deploys successfully but isn't visible to users — for a Fusion Redwood page extension, the sandbox still needs to be published/activated separately from the VB Studio deployment.
• Production ends up different from what passed Test because a fresh Build ran against Production instead of promoting the already-tested artifact — always confirm it's a Promote, not a new Build, going into Production.

Next Steps