Part 8: Extending HCM Redwood with VB Studio — Deploying Module Changes

Before we dive into Part 8, here’s a quick recap of where we’ve been 👇

𝗣𝗮𝗿𝘁 𝟲 — 𝗜𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁𝗶𝗻𝗴 𝗕𝗿𝗮𝗻𝗰𝗵𝗶𝗻𝗴 𝗠𝗲𝘁𝗵𝗼𝗱𝗼𝗹𝗼𝗴𝘆
In Part 6, we laid the entire foundation — one shared project, an auto-provisioned infrastructure, and three clean branches (Core HR, Performance, and Learning) each stemming from main and owned by their respective SME. (Haven’t read this yet? Start here first before moving ahead 👇)
🔗 https://medium.com/@saurabhpratap.singh/part-6-extending-hcm-redwood-with-vb-studio-implementing-branching-methodology-c922c1dd0835

𝗣𝗮𝗿𝘁 𝟳 — 𝗪𝗼𝗿𝗸𝗶𝗻𝗴 𝘄𝗶𝘁𝗵 𝗕𝗿𝗮𝗻𝗰𝗵𝗶𝗻𝗴 𝗠𝗲𝘁𝗵𝗼𝗱𝗼𝗹𝗼𝗴𝘆
In Part 7, we watched those branches come alive — Andy, Christina, and Michael each personalizing their own pages, committing, and pushing — fully independently, with zero risk of stepping on each other’s work.. (Not caught up yet? Read this before continuing 👇)
🔗 https://medium.com/@saurabhpratap.singh/part-7-extending-hcm-redwood-with-vb-studio-working-with-branching-methodology-ba958f3ceb1d

All caught up? Great — because in 𝗣𝗮𝗿𝘁 𝟴, we close the loop and deploy everything to higher environments, selectively and independently, through the pipeline. 🚀

But here’s where the real enterprise question surfaces. 👇

Each branch works perfectly in isolation. But what happens when you need to test them together?

That’s exactly what the Integration Branch is for.

What Is an Integration Branch?

Think of your module branches — core-hr, performance, learning — as parallel tracks, each carrying its own set of changes, each tested in isolation. Now imagine your UAT team sitting down and asking:

“Can we see everything together — exactly as it would look in production?”

That’s the moment your module branches need to converge somewhere before they touch main. That somewhere is the Integration Branch. 🌿

An Integration Branch is a dedicated branch in your VB Studio Git repository that acts as a controlled staging ground — a place where two or more module branches are merged together so they can be tested as a unified whole, without any of those changes being promoted to main.

It is not a delivery branch. It is not a module branch. It sits deliberately between the two — a middle layer purpose-built for combined testing before anything gets finalized.

How to Create and Use the Integration Branch

The mechanics live in the same place you created your module branches in Part 6 — Git → Refs — but there’s one critical decision to make before you hit Create. 👇

Step 1: Confirm Which Module Has the Most Changes

Before creating the integration branch, pause and answer this question:

Which module branch carries the highest number of changes in this release cycle?

This matters because the Base branch you select when creating the integration branch determines the starting point of everything that follows. Whichever module branch you choose as the base will have its changes already present in the integration branch the moment it’s created — no merge step needed for that module.

In a real enterprise release, one module will almost always carry more changes than the others — more Business Rules, more page personalization, more commits. For this walkthrough, we’ll assume Core HR carries the highest number of changes, making core-hr our natural choice as the Base branch. ✅

The principle holds regardless of sprint size: always identify the heaviest module branch first, then use it as your base. Everything else gets merged in on top.

Step 2: Create the Integration Branch

Inside your VB Studio project:

a) Git → Refs → Create Branch

The New Branch dialog appears. Two things to configure:

Name — Give it a name that tells the story at a glance. Notice the naming convention used here: IntegrationBranchCoreHRPerformanceTalent13062025 — the branch name encodes exactly which modules are included and the date of creation. No ambiguity, no guessing.

Base — Set this to your highest-change module branch. In our case, core-hr.

💡 Pro Tip on Naming: Always embed the module names and date into your integration branch name. When you’re managing multiple sprints and multiple integration cycles, integration as a branch name tells you nothing three weeks later. IntegrationBranchCoreHRPerformanceTalent13062025 tells you everything.

This means the moment the branch is created, all of Andy's Core HR changes are already inside it. One module down, two to go.

b) Click Create.

Here’s the magic moment. 🪄

The moment you hit Create, switch to the integration branch in the Logs view and you’ll see this:

Core HR change — enforcing the Position field as mandatory on the Hire an Employee page — is already sitting right there, tagged and visible, the instant the branch is created. No merge step, no manual action, no waiting. Because core-hr was the Base, its entire commit history came along for free.

This is exactly why choosing the right Base branch matters. Your heaviest module’s changes land immediately — and you only need to actively merge in the remaining lighter modules on top.

Step 3: Migrate Remaining Module Changes via Advanced Mode in VBS

The integration branch is now live with Core HR changes inside it. But Performance (Christina’s) and Learning (Michael’s) changes still live in their own isolated branches. They don’t automatically flow into the integration branch — you have to bring them across deliberately.

This is done through Advanced Mode in Visual Builder Studio — not through the Git Refs panel.

a) Open any Redwood HCM page and click “Edit Page in Visual Builder Studio.”

This is your entry point into VBS. It doesn’t matter which page — you’re not here to personalize anything. You’re here to switch branches.

b) Switch to Advanced Mode using the toggle in the top-right corner.

Advanced Mode is where your workspace connects to Git — this is the control room for everything branch-related. Express Mode is for personalization's. Advanced Mode is for branch management. Make sure you’re in the right one before proceeding.

c)Click the branch/sandbox indicator and select Switch Branch / Sandbox from the dropdown.

The Switch Branch/Sandbox dialog opens. Click the Branch dropdown — you’ll see both Local Branches and Remote Branches listed. Scroll down to the Remote Branches section and select IntegrationBranchCoreHRPerformanceTalent13062025. 👇

Your workspace is now pointing at the integration branch

d)Merging the branches into Integration Branch

Here’s where most teams get confused — and get it wrong. ⚠️

Let’s walk through merging the performance branch first.

a) Click the Git options menu and select Merge.

With your workspace already switched to the integration branch (from Step 2), open the Git panel’s menu and click Merge.

b) Select the branch you want to merge in — performance first

A branch picker appears showing all Remote Branches. Select performance from the list.

c) Click Merge to start the merge

Get Saurabh Pratap Singh’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

VBS confirms it’s merging a remote branch and will run a git fetch first to make sure everything is current. Click Merge.

d) If a conflict surfaces, click Show Conflicts

In our case, the merge doesn’t go through cleanly — VBS flags that there’s a conflict in 1 file. This is exactly the kind of thing the integration branch exists to catch early. Click Show Conflicts.

e) Review the conflicting file in the Git panel

The Git panel now shows a Merge Interrupted banner with Abort and Continue options, and lists the conflict under Conflicts (1) — in our case, extension.json

f) Open the conflicting file and resolve it

Click on extension.json to open it. VBS shows the file was modified by both you (the integration branch) and them (the performance branch), with the conflicting block clearly marked using standard Git conflict markers (<<<<<<< HEAD, =======, >>>>>>> refs/remotes/origin/performance)

Click Use their version to accept the incoming change from the performance branch

⚠️ Note: “Use their version” vs “Use your version” is a judgment call, not a default. Review what’s actually conflicting before choosing — in our case, the performance branch’s dependency version is the one we want carried forward.

g) Click Resolve and Close once there are no unresolved conflicts

After selecting the correct version, the conflict indicator updates to No unresolved conflicts. Click Resolve and Close.

h) Click Continue to finish the merge

Back in the Git panel, the Merge Interrupted banner is still showing. Now that the conflict is resolved, click Continue.

i) Push the merged result to the remote integration branch

Open the Git options menu again and click Push.

The Push dialog confirms your commits are headed to the correct remote — origin/IntegrationBranchCoreHRPerformanceTalent13062025. Click Push Changes

j) Repeat steps a–i for every remaining branch in scope.

Next up: learning. Same sequence — Merge → select learning → Merge → resolve any conflicts that surface → Continue → Push → Push Changes

Step 4 : The Integration Branch — Fully Assembled

After repeating the merge sequence for learning, the integration branch now carries every module's changes in its commit history — Core HR, Performance, and Learning, all merged in cleanly, all pushed to the remote

This single branch now gives the UAT team exactly what they need — one environment, one deployment, every pending personalization visible and testable together. No more module-by-module testing in isolation. No more guessing how Core HR, Performance, and Learning will behave when a real end-to-end business process runs across all three.

Step 5 : Deployment Process

With the integration branch fully assembled — Core HR, Performance, and Learning all merged in and pushed — it’s time to close the loop. Everything that’s been built, committed, pushed, and integrated now needs to move through the pipeline and land on a higher environment.

a) hcm_extension-Package Configuration

Navigate to Builds in the left panel. You’ll see your two auto-created jobs — hcm_extension-Deploy and hcm_extension-Package.

Click into hcm_extension-Package, then click Configure.

In Job Configuration, the Git tab is selected by default. Under Auto Branch, update the Branches field to point at the branch you want packaged — in our case, IntegrationBranchCoreHRPerformanceTalent13062025

⚠️ This is the step people skip. If the Package job is still pointing at main or an old module branch, you'll deploy the wrong code — or nothing at all. Always confirm the branch name here matches exactly what you intend to ship.

Click Save

The Package job is now fully pointed at the integration branch. ✅

b. hcm_extension-Deploy Configuration

Go back to Builds and click hcm_extension-Deploy.

Click Configure

Go to the Steps tab. Under Application Extension Deployment, set the Target Instance to the environment you’re deploying to — in our case, an Oracle Applications Cloud (Fusion) instance. Choose your authorization method (Use Basic or Use OAuth) and provide the Username and Password for that instance.

⚠️ Common Mistake: Pointing the Deploy job at the wrong target instance. Always double-check this matches your intended UAT or higher environment — there’s no undo once a pipeline run completes.

Click Save.

The Deploy job now knows exactly where to send the packaged artifact. ✅

Step 3: Run the Pipeline

Go to the Pipelines tab and locate hcm_extension-Package_and_Deploy. This pipeline was auto-created back in Part 6, designed to run Package and Deploy sequentially — exactly the order you need

The pipeline runs both jobs in sequence — first packaging your integration branch into a deployable artifact, then deploying that artifact to your configured target instance.

Once the pipeline completes, your changes — Core HR, Performance, and Learning, all merged and tested together in the integration branch — are live on the target environment. ✅

Summary

In this article, we covered:

• Why testing module branches in isolation isn’t enough — and how the Integration Branch lets Core HR, Performance, and Learning be merged, conflict-checked, and tested together before anything reaches main.
• How choosing the right Base branch and migrating the remaining modules through Advanced Mode in VBS — including resolving a real merge conflict in extension.json — builds a fully assembled, UAT-ready branch.
• How configuring hcm_extension-Package and hcm_extension-Deploy, then running the pipeline, takes that integrated branch all the way through to deployment on a higher environment.

This wraps up the full branching methodology series — from a single shared project, to isolated module branches, to a unified integration branch for combined testing, to a clean, repeatable deployment pipeline. 🚀