RPD Development Workflow: Multiuser Development & Deployment

Explain how teams collaborate on a single RPD using Multiuser Development (MUD) and how changes are deployed across environments.

A single binary RPD file is not naturally collaborative — two developers can't edit it simultaneously the way they could edit separate files in source control — so OBIEE provides Multiuser Development (MUD) to let teams work on the same repository in parallel without stepping on each other, and interviewers use this to gauge whether you've worked on a real team-based RPD project versus a solo sandbox.

MUD is like a shared Google Doc where each person is assigned their own section to edit offline, and a merge tool stitches everyone's sections back together at the end, flagging any spot where two people edited the exact same sentence so a human can decide which version wins.

Key Concepts

In MUD, the RPD is divided into logical projects (a subset of subject areas/business model objects assigned to a team or workstream). Each developer checks out only the project(s) they need, works offline against a local copy, and then checks in their changes, which are merged back into the shared master RPD by the MUD merge process — conceptually similar to a version-control merge, with the Administration Tool presenting conflicts for manual resolution when two developers changed overlapping objects.

projects

Beyond MUD, the broader deployment lifecycle typically follows Dev → Test/QA → Production promotion, using tools like the Repository Merge/Patch functionality (comparing an "original," "modified," and "current" RPD three-way merge) or, in more modern deployments, BAR (BI Archive) files that bundle the RPD, catalog, and configuration together for deployment via WLST or Enterprise Manager, especially relevant in OAC/cloud deployments. Environment-specific values (connection pool credentials, physical database names) are typically parameterized or adjusted post-deployment so the same logical model works across environments without manual rework each time.

deployment lifecycleRepository Merge/PatchBAR (BI Archive) files

Interviewers may probe your experience with merge conflict resolution — knowing that MUD conflicts require careful review (not blind "accept theirs") because silently accepting the wrong side of a conflict can quietly reintroduce a bug that was already fixed.

merge conflict resolution