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.

An RPD is one binary file. Two people cannot edit it at once the way they would edit source files, which is the problem MUD exists to solve.

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

How MUD works.

    a shared master RPD, in a network directory
      divided into projects -- subsets of the model

    developer A  checks out project "Sales"
    developer B  checks out project "HR"
      each works offline, on a local copy
      each checks in; the merge combines them

The merge is three-way: original, yours, theirs — the same model as a version control merge, applied to model objects rather than lines.

Projects are how conflicts are avoided. Two developers checking out projects that share objects will conflict on them, so projects are drawn along the seams of the model.

MUD is not source control, and this is worth being clear about. It handles concurrent editing. It does not give you history, branches, or a diff you can review.

Teams therefore keep the RPD in version control as well — committing the binary after each significant change — and use the Administration Tool's compare feature to produce a readable difference between two versions.

Deployment across environments.

    develop offline -> compare against the target -> deploy

Connection pool settings differ per environment, so the RPD must be adjusted on deployment. Doing that by hand is where mistakes happen — a test RPD deployed with production connection details, or the reverse.

biserverxmlexec and the patch mechanism support scripted deployment, which is what makes it repeatable.

biserverxmlexec

Patching is the alternative to wholesale replacement. Generate a patch describing only the changes between two RPDs and apply it to the target:

    compare dev RPD against prod RPD -> a patch file
    apply the patch to prod

That preserves environment-specific settings in the target instead of overwriting them, which is the main argument for it.

Online and offline editing. The Administration Tool can edit a deployed RPD live. It is convenient and it applies changes to a running server with users on it, so the normal practice is to work offline and deploy deliberately.

The consistency check before anything. The Administration Tool validates the model — missing joins, unmapped columns, hierarchies without keys. An RPD with errors will not deploy, and running the check before a merge rather than after saves the merge being redone.

What the interviewer is probing.1. "How do several developers work on one RPD?" Probing: the mechanism. Stalls: "Take turns." Moves up: multiuser development with projects — each checks out a project, works offline, and merges back against the master.

2. "What is the alternative in practice?" Probing: honesty. Stalls: "There is none." *Moves up:* many teams serialise changes with a checkout discipline, because MUD merges are painful and the RPD is a binary file.

3. "How is an RPD promoted between environments?" Probing: the process. Stalls: "Copy it." Moves up: patch files or a full deployment with connection pool details supplied per environment, so credentials are not carried across.

4. "What testing do you run after a deployment?" Probing: the discipline. Stalls: "Open a dashboard." Moves up: consistency check, then a regression set of analyses with known expected numbers — a valid RPD can still return wrong results.