MUD is a set of features that enables teams of developers to work in parallel on projects of any size, despite the complex interrelationships and dependencies in the repository model.
With MUD, you can:
Divide the repository file into subsets
Enables users to work with manageable subsets when the repository is very large
Enables independent testing for each subset by each developer or team
Makes it easier to manage merges later after checking out a branch subset
Enables you to separate independent semantic models into secure branches for development
Incrementally develop, test, and migrate
Merge subsets and branches, handling conflicts between user changes
Apply Oracle updates to a packaged BI Application you have modified
Merge separately developed applications into a single repository
Access history logging and audit information
Roll back to historical repository states
The multiuser development feature also provides the following other useful capabilities:
Coordinates merging into the master, including tracking original repository files
Provides locking for reliable updates
Logs changes
Automatically backs up repositories before each potentially destructive operation
This section contains the following topics:
Learn the basics for working with multiple users in a development environment.
The basic flow of working with multiple users is as follows:
A developer defines the "starter" Physical layer, as well as basic facts and subject areas. This provides some basic objects to anchor the MUD projects.
The MUD administrator defines projects and puts the RPD into the main branch MUD directory.
Note:
The MUD directory where the master repository is stored cannot be the same as the Oracle BI Server local repository directory.
A developer can now check out one or more projects, do development work, and then merge the changes into the master by publishing to the MUD directory.
Meanwhile, other developers check out and do development on the same or other projects (note that projects are for subsetting, not for enforcing security). Because the publishing step uses a three-way merge, users can check out, develop, and publish their changes in any order. Even property changes to a single object from multiple users are merged. If conflicts do occur between users, the three-way merge feature provides a way for the developer to choose which objects to keep. Communication between users is a key to avoiding and resolving conflicts, and you should have your governance process assign ownership of major objects in order to avoid such conflicts.
When a development phase is complete, the MUD administrator can migrate the content to a test system. There might be several iterations back through check out, bug fix, publish, and retest. When the repository passes the testing phase, the MUD administrator can migrate it to the production environment.
The MUD administrator can create and manage multiple development branches as large MUD projects. A branch can be secured to ensure that only one development team can work on it. A branch can even be treated recursively as a main, with its own, delegated MUD administrator.
The multiuser development feature is built around a metadata object called a project. The project is the unit of check-out from the master repository, and the subsequent merge and publish.
When a master repository becomes very large, a project is a manageable-sized subset that a developer can check out to work on. It is also designed to be self-consistent, so that you can run the consistency checker (analogous to compile-time code checking) and then test it on the Oracle BI Serverwith a client such as Answers at run time. When you are satisfied with the results, you can merge it back into the master repository so that it becomes part of the larger application. Meanwhile, history is logged and repository backups are automatically created at key points.
MUD features in the Administration Tool streamline this flow for fine-grained developer projects. Similarly, superset projects streamline the management and merging of branches.
The project subset contains a set of metadata objects. You define a project to include a minimum set of objects explicitly, but many others are included implicitly. Having objects implicitly added to projects simplifies your project management task.
The following objects are explicitly specified by the MUD administrator as members of a project:
Logical fact tables
Presentation layer subject areas
Application roles
Users (although the best practice is to only use application roles in RPD logic)
Initialization blocks
Variables
All other objects are implicitly included in a project and are found by the Administration Tool during the check-out process. For example:
Descendents of the explicitly defined objects. For example, when a logical fact table is included explicitly, all its logical columns are included in the project implicitly.
Logical dimension tables that join to the selected logical fact tables, and the join objects themselves.
Logical table sources for the included logical fact and dimension tables.
Physical tables that map to the logical tables included in the project, and the joins between them.
Marketing target levels and list catalogs.
Note that objects that are in the list of explicitly defined objects are sometimes included implicitly. For example, if a logical column contains an expression that includes a variable, the variable is implicitly included in the project, even if the MUD administrator does not explicitly add it.
It is normal for projects to overlap. An object that appears in one project can also appear in another project. For example, some customers prefer to create an overall project for each independent semantic model, as well as smaller projects within each independent model for checking out individual units of development work. You can also check out multiple projects simultaneously to work on a larger set of metadata.
See also Setting Up Projects for additional information.
Learn how to create main branches, side branches, and delegated administration branches.
This section contains the following topics:
The ultimate master repository is usually source-controlled in the main branch, out of which all branches and ultimately all development projects check out.
The main branch usually stages the repository in production. That is, to migrate content to production, you merge it into the main branch, and then migrate the main repository to the production system.
Similarly, to fix a production bug, a developer typically checks out of the main branch. The developer then fixes the bug, and then merges it back into the main branch for migration to test and production. Meanwhile, parallel development in side branches is not affected.
To create the main branch as the MUD administrator, you must first create a shared directory and copy the master repository file to it. The directory can be on either Windows or UNIX, but the UNIX share must be accessible by Windows users.
Set the security on the share to only allow access by the appropriate developers. Depending on your requirements, you might only allow developers to access the side branch master repositories, not the main branch master repository.
If this is a new project, you typically have a developer seed the repository with initial content that can be easily split into branch projects.
The best practice for branching is to start with a superset MUD project, and then use the MUD check-out, merge, and publish features. Then, individual users or sub-branches use finer-grained projects and check out of the branch master. Using MUD for this functionality provides automatic back-ups at the check-out points, tracks original repositories to ensure correct merges, uses more optimistic merge assumptions that require less user intervention, and provides history and roll-backs.
To create a side branch as the MUD administrator:
You can use a branch to delegate local control of a metadata subset to the organization that is developing and maintaining it. To do this, you assign a branch MUD administrator to the branch, who performs the same roles as the main MUD administrator.
This approach works best with an independent semantic model, so that you can ensure that there is no metadata overlapping with other groups.
The delegated branch MUD administrator performs the same tasks as the main branch administrator, including defining projects for further branches and creating fine-grained projects for developers.
To create a delegated administration branch as the main MUD administrator:
Set permissions on the main MUD directory so that only the main MUD administrator, and the main MUD administrator backup, have access.
Create a branch MUD project, branch MUD directory, and checked-out branch master repository as described in the previous section.
Set security on the branch MUD directory so that the main MUD administrator and the delegated branch MUD administrator have access.
The branch administrator defines projects for further branches, as well as fine-grained projects for developers. If required, the branch administrator deploys additional branches off the delegated branch for development initiatives, with permissions set to allow developers to check out of these repositories.
Developers fix production bugs by checking out of the delegated branch MUD directories, because individual developers are not allowed access to the main branch.
When developers publish all their changes, the branch administrator checks their branches into the delegated branch for integrated testing.
To promote a delegated branch to production after integrated testing is complete, the main MUD administrator performs the following two steps:
Removes the branch master repository from the delegated branch repository shared directory and checks it back into the main branch using the Administration Tool.
Migrates the main branch master repository to production.
Typically, the main MUD administrator checks out the branch again and places the branch repository in the delegated branch shared MUD directory for the next phase of development. The branch administrator then checks out next-level branches and places their repositories into the branch shared MUD directories, so that developers can check out their fine-grained projects and begin their work.
There are several different merge tools that are optimized for various situations and environments.
When deciding which merge approach and utility to use, you should consider whether you need to perform the task on Windows or UNIX systems. You should also consider your other requirements, such as whether you need to merge changes you made to a semantic model, or whether you need to combine two semantic models from different development efforts.
Important
When using Oracle BI EEtools such as nqcmd, biserverxmlcli, and comparerpd, you must edit the input to match the format expected by SQL, for example, do not include a single quote in your XML content.
The table shows which merge approaches and tools meet various requirements.
| Requirement | Merge Approach | Tools Used | Platform |
|---|---|---|---|
|
Three-way merge |
MUD merge |
Windows |
|
Three-way merge |
In the Merge Repository Wizard use Full Merge. |
Windows |
|
Three-way merge |
In the Merge Repository Wizard with Patch Merge selected use the Patchrpd utility. |
|
|
Two-way merge |
In the Merge Repository Wizard select blank original. |
Windows |
|
Insert-Update-Delete |
Copy/Paste XML |
All |
|
Insert-Update-Delete |
|
Windows |
See Merging Repositories for more information about merging.