Oracle Fusion Cloud Code Merge Flows: From Feature Branch to Production

Six merge flows for Oracle Fusion Cloud on VB Studio: emergency hotfixes, two-step go-lives, and the Forward-Merge cascade that keeps parallel release streams building on current production code. Part 2 of the series.

Branches are the easy part. The hard part is what happens between them: the actual path a change takes from a developer’s workspace to production, and whether that path is the same every time or improvised under pressure.

Part 1 of this series laid out the branch architecture and the four CI/CD pipelines. This one covers the flows that run on top of them, the documented, gated routes that move code from a feature branch to Oracle Fusion PROD without anyone breaking production on the way.

There are six of them. They handle emergency hotfixes, phased release go-lives, and the forward propagation of changes across parallel environments. Each has a fixed starting point, a fixed set of CI gates, and a defined thing that happens once the production deploy succeeds. If you haven’t read Part 1 on the branch model and pipeline definitions, start there, because everything below assumes it.

The Six Flows at a Glance

All six flows end in the same place: Oracle Fusion PROD, which is the main branch. What separates them is where they start, which CI gates they pass through, and what has to happen after the production deploy lands.

• M&O Hotfix: Ticket-based, P1/P2/P3 severity. Branch from main. CI P2 to M&O TEST, then CI P1 to PROD. Forward-Merge to all active Rx branches within 48 hours.
• Release R1 flow: Feature to CI P4, then CI P3 SIT, then CAB approval, then a two-step go-live to PROD. Forward-Merge to Release 2 and Release 3 after go-live.
• Release R2 flow: Same pattern as R1. Forward-Merge to Release 3 after go-live.
• Release R3 flow: Same pattern. No Forward-Merge afterward, since R3 is the last active stream.
• Post-Hotfix FM cascade: main to development to R1 to R2 to R3, all inside 48 hours, with CI P3 validating every hop.
• Post-Release FM cascade: main to development to every remaining active Rx branch after any release go-live.

M&O Hotfix Flow, Step by Step

The hotfix flow handles production issues without disturbing any in-flight release. It’s fast, but never careless. Every step passes through a gate, and none of the gates are optional.

Step 1: Create the branch from main. Raise a ticket with the right severity (P1, P2, or P3), then cut the hotfix branch straight from main HEAD: git checkout -b hotfix/INC-5678-gl-import. You work in a dedicated M&O TEST VB Studio workspace scoped to this ticket and nothing else. At this point, main and every Rx branch are completely untouched.

Step 2: Build and push the fix. Open an isolated VB Studio workspace for the ticket. Build the Redwood-compliant fix, commit, and push. CI Pipeline P2 fires automatically on every push to hotfix/*. Need to undo a bad commit? git reset HEAD~n, then push again. P2 re-runs on its own.

CI Gate: Pipeline P2 (M&O TEST deploy). P2 runs ESLint, JET Audit, and a full regression suite against the M&O TEST environment. It’s a hard pass or fail. No merge to main happens until P2 is green, and a red badge means you can’t even open the PR.

Step 3: Open a PR to main. With P2 green, raise a pull request from hotfix/* to main. You need two reviewers, and the M&O Lead has to be one of them. The P2 badge has to read green on the PR. The only way past a red badge is dual written sign-off from the Release Manager and the DevOps Lead, and that's deliberately hard to get.

Step 4: CAB approval. Open a change record for the planned production change. P1 incidents get a verbal CAB approval targeted at under four hours. P2 and P3 incidents go through the weekly CAB slot. Whatever the severity, you need at least two approvals plus Release Manager sign-off before the merge can go ahead.

Step 5: Merge to main and deploy to PROD. Once the PR is approved, merge hotfix/* into main. CI Pipeline P1 promotes the artifact to Oracle Fusion PROD automatically. Tag it right away: git tag mando/INC-5678. Then run a 24-hour monitoring window. If you need to roll PROD back, git revert HEAD on main, trigger a P1 re-deploy, run smoke tests, and tag the revert, for example reverted/INC-5678.

Step 6: Forward-Merge within 48 hours. This step is mandatory. It doesn’t get skipped. Run the Forward-Merge in order: main to development, then development to R1, R2, and R3 in sequence. CI P3 validates each hop before the next one starts. The Release Manager confirms the FM dashboard is green before closing it out. If one hop fails, revert that hop on its own and let CI P3 re-run for that branch alone.

Release Flow: Feature Branch to PROD

The release flow is the long road, from a developer’s feature branch all the way to a production deploy. Every release stream runs the same pattern, no matter its number.

Step 1: Create the feature branch. Raise a JIRA ticket for the work, then branch off the active release branch: git checkout -b feature/R1/GL-ORA-4521. The source is the release/Rx HEAD. Deleting this branch later has zero impact on main, development, or any other Rx branch.

Step 2: Build in an isolated DEV workspace. Open a VB Studio workspace scoped to this developer and this feature. Build the Redwood-compliant extension, commit, and push. CI P4 fires on every push to feature/Rx/*. To undo, git reset HEAD~n and push again.

CI Gate 1: Pipeline P4 (Rx-DEV deploy). P4 runs ESLint, JET and Redwood Audit, and workspace validation. Pass, and the developer can open a PR to the release branch. Fail, and the PR stays blocked until the code is fixed and the pipeline runs green.

Step 3: Merge feature to release/Rx and trigger SIT. With P4 green, open a PR from feature/Rx/* to release/Rx. You need two reviewers plus the green P4 badge. On merge, CI P3 auto-triggers and runs the full SIT regression suite against the Rx-SIT environment. If SIT fails, revert the merge on release/Rx and P3 re-runs automatically.

CI Gate 2: Pipeline P3 (Rx-SIT deploy). P3 builds the VB artifact, deploys to the Fusion SIT environment, and runs the automated regression suite. This gate blocks everything downstream until it’s green. While P3 is red, no feature PRs merge to the release branch.

Step 4: Business UAT and CAB. With P3 green, business teams run UAT in the Rx-SIT environment. Raise a change record for the go-live. CAB here means a full panel, a two-week lead time, at least two approvals, and Release Manager sign-off, with a mandatory rollback plan. If UAT fails, re-open the UAT window and reschedule CAB.

The Two-Step Go-Live

Going live is deliberately two steps, not one direct merge to main. That’s a safety mechanism, not red tape.

Step 1: Merge release/Rx into development through a buffer PR. That creates an integration checkpoint the Release Manager reviews before anything touches main.

Step 2: Merge development into main. CI P1 picks up the merge and promotes the artifact to Oracle Fusion PROD. Tag it immediately: git tag vX.0.0. Run a 24-hour monitoring window afterward.

The logic is simple. Development is a pre-PROD integration layer. When several releases go live close together, development is where last-minute conflicts surface before they reach PROD. A direct release-to-main merge would skip that net entirely and cut out the Release Manager’s final review.

Get Vasim Imani’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

If PROD needs a rollback after go-live: git revert HEAD on main, trigger a P1 re-deploy, run smoke tests, and tag the revert as vX.0.0-reverted.

Once the release branch has merged completely and FM has finished, delete the release/Rx branch and every feature/Rx/* branch tied to it. Keep the repo clean.

Forward-Merge Cascade: Keeping Every Environment Current

Every production event kicks off an FM cascade that has to finish within 48 hours. Which cascade you run depends on what caused the PROD event.

Post-Hotfix FM cascade.

After a hotfix merges to main, the cascade runs in this order:

• main to development
• development to release/R1
• development to release/R2
• development to release/R3
• CI P3 validates every single hop before the next one starts
• every Rx-DEV and Rx-SIT environment receives the hotfix code
• if a hop fails, revert that specific hop, let CI P3 re-run, and that branch heals on its own without touching the others

Post-Release FM cascade.

After a release go-live (using Release 1 as the example):

• main to development
• development to every remaining active Rx branch (Release 2 and Release 3)
• CI P3 validates every hop
• PROD is not touched by any FM cascade rollback
• if a hop fails, revert the FM merge on that specific Rx branch and let CI P3 re-run for it

The point of the cascade is that no active release branch is ever building on a stale production baseline. Without it, a hotfix that shipped to PROD on Monday could collide with a release going live the next week, because that release branch never got the fix. With the 48-hour boundary enforced and every hop validated by CI P3, every active branch is always built on current production code.

Rollback Strategy at Every Level

A complete architecture has a rollback path for every stage of every flow. Here is the full reference.

• DEV rollback (hotfix): Delete the hotfix branch. The isolated VB Studio workspace goes with it. Zero impact on main or any Rx branch.
• DEV rollback (feature): Delete the feature branch. The isolated DEV workspace is removed. Zero impact on the release branch or any other environment.
• Code fix during development: git reset HEAD~n, then re-push. CI P2 or P4 re-runs automatically.
• SIT rollback (feature merge): Revert the merge on release/Rx. CI P3 re-runs automatically. Other features already in SIT are unaffected.
• SIT rollback (FM hop): Revert the FM merge on the specific Rx branch. CI P3 re-runs for that branch only. The other Rx branches heal independently.
• PR rollback before merge: Close the PR, fix the code, re-push. CI re-runs. No bypass without dual sign-off.
• PROD rollback (hotfix): git revert HEAD on main, CI P1 re-deploys the previous artifact, run smoke tests, tag as reverted/INC-[id].
• PROD rollback (release): git revert HEAD on main, CI P1 re-deploys, run smoke tests, tag as vX.0.0-reverted.
• CAB rollback: If CAB approval isn’t achieved, re-open the UAT window and reschedule. No code advances until CAB is cleared.

The design follows one principle: every environment rolls back on its own. A failed FM on Release 3 doesn’t mean rolling back Release 1 or Release 2. A PROD rollback doesn’t disturb an FM cascade already in progress.

Putting It All Together

The six flows aren’t separate processes. They’re one connected system. A hotfix flow reaches into every release flow through the FM cascade. A release go-live resets the FM baseline for every remaining active release. Every flow feeds the same main branch and the same PROD environment.

The piece that matters most is the Forward-Merge discipline. Most teams have branching figured out. Far fewer enforce FM consistently, and that gap is exactly where technical debt piles up in Oracle Fusion implementations. Enforce the 48-hour boundary, validate every hop with CI P3, and keep FM status on a dashboard the Release Manager checks after every PROD event.

Run the branch architecture from Part 1 and these code flows together, as one system. Partial implementation leaves gaps, and gaps grow into incidents. The strength here is that every rule, every gate, and every FM step connects to the others. Implement it fully and the system starts enforcing itself.