Mark Rittman once joked during a presentation on OBIEE and SCM that “MUDE” (multiuser development environment) was the closest thing to a dirty word in the OBIEE documentation. I know many people who feel that way… some justified, some perhaps not, as MUDE has certainly gotten better in the later releases of OBIEE. As I mentioned in the introduction, I’d like to introduce MUDE in this post to set the stage for, at the very least, how good a competing multiuser development methodology would need to be. I’m not a genuine fan of MUDE… but I promise not to present a straw man to rip apart in my later posts. If you feel I don’t give it a fair shake, please comment and let me know. If you are interested in some other thorough treatments around MUDE, Venkat wrote about it on his old blog when the feature was first introduced in 10g, as did Mark here on this blog.

Let me start by putting forth what I think are the SDLC (software development life-cycle) imperatives that any solution to metadata development (or any other kind of development) should tackle without question:

1. Multiple users should be able to develop concurrently… but we need to be clear exactly what we mean by this. Having all the developers login to a shared online repository is one way to do multiuser development… but this equates to multiuser development using serialized access to objects. Whether explicit or not in the requirements… what most organizations want is non-serialized access to objects… meaning that multiple users can be making changes to the same objects at the same time, and we will be able to merge our changes together, and handle conflicts.
2. Our VCS should give us the ability to rollback to previous versions of our code, either for comparative purposes… or because we want to rewind certain streams of development because of “wrong turns”.
3. Our VCS and supporting methodology should provide us the ability to tag, secure and package up “releases”… to be migrated to our various environments eventually finding their way to production.

So let’s see if MUDE is up to the challenge. To enable MUDE, I start by defining one or more Projects in my binary RPD. So, I open the RPD in the Admin Tool, choose the Manage option from the toolbar, and select Projects… from the drop-down list:

Next… I choose all the objects I want to include in the project. Our choice for which logical tables to include from the Business Model (BMM) is driven by which logical fact tables we choose, using either individual Presentation Subject Area measure folders, or explicit BMM logical fact tables. We also select any other objects we want to include in the project: explicit Presentation layer folders, init blocks, variables, etc.:

Once we have configured one or more projects in the repository, we then take the binary RPD file and place it on a network share accessible to all developers. From here on out, the RPD file is referred to as the Master Repository. Now, whenever we want to check out a project from the Master Repository, we register the shared network drive location in the Admin Tool. We get to the configuration screen by choosing Tools and then Options… and then choosing the Multiuser tab:

Once a Master Repository exists in the development directory specified in the Admin Tool, we are then able to check out a project from the Master Repository. To check out a project, we choose the File menu, and from the drop-down menu, we select Multiuser and then Checkout… after that. Then we choose the project we want to checkout:

The Admin Tool now prompts us to create a new “subset repository”. This is a fully-functioning binary RPD file containing only the subset of objects that were defined in the project. We can call this RPD anything we like–in my example I called it gcbc_project1.rpd–and it will exist in the “repository” directory buried in the bifoundation directory underneath our instance directory, for instance: [middleware_home]\instances\instance1\bifoundation\OracleBIServerComponent\coreapplication_obis1\repository:

Once we have checked out our project, it’s interesting to see the files that the Admin Tool generates behind the scenes to manage MUDE. If we look in the Master Repository directory (this was the C:\master directory we configured in the screenshot above), we should have the following files:

• gcbc.rpd: The original Master Repository binary RPD file
• gcbc.000: A backup of the Master Repository RPD file. We will constantly see new versions of the backup file as development continues on the Master Repository, and we’ll see the numeric extension increment over time.
• gcbc.mhl: The history file… this tracks all the history of changes, when they were performed, and by whom. This file can be output to an XML file using the mhlconverter utility so that it’s readable without the Admin Tool.

Now, if we look in our local repository directory, we have the following files:

• gcbc_project1.rpd: The subset binary RPD file we created when we checked out our project above.
  
• originalgcbc_project1.rpd: Initially… this is an exact copy of the subset binary RPD at the time of checkout. It will not be affected by changes to the actual subset RPD, as it’s purpose is to serve as the “original” copy of the RPD during the 3-way merge. Also… it facilitates the Discard Local Changes options in the Multiuser menu option.

In looking at this infrastructure… there’s nothing magic happening here: MUDE simply uses the basic functionality of the Merge… and the Compare… that are built into the Admin Tool. I’m not saying this disparagingly. There’s no reason to maintain the code path for two different versions of a 3-way merge. MUDE is really nothing more than a framework for making the Compare… and Merge… functionality easier and more predictable. So, it’s not shocking when we choose Compare with Original… from the Multiuser menu and see a screen identical to the basic Compare… option without MUDE:

Similarly, when we choose the multiuser option Publish to Network… we see a window identical to the standard Merge… option in the Admin Tool:

So this was a high-level look at MUDE… hopefully I’ve done it justice. Now I’d like to discuss where I think MUDE comes up short as a competent VCS, or SCM… or whatever solution we think it is. On our list of the three imperative boxes that a metadata development solution should tick, I think number (1) is a slam-dunk. Although there have been issues with MUDE… almost every BI or ETL tool I’ve worked with over the years has issues in this area. I think there is also a fair argument to be made that MUDE also ticks the boxes for (2) and (3). But is it complete enough in the areas?

Although MUDE provides us the ability to interact with previous versions of our code, it does this with a “siloed”, metadata-only approach. If I were building an entire BI solution, I would want to associate my metadata repository with my web catalog, and also presumably with my database DDL scripts and ETL routines, regardless of which tool I used for that. MUDE only handles the RPD. If I could somehow figure out how to use a standard VCS such as Git or Subversion to check in all my code into one place, then I could see how everything looked at a particular point in time. The same goes with tagging and packaging releases. MUDE makes it easy to prepare a binary RPD file for release, but it provides no benefit when it comes to packaging a release for the entire BI system. I want a more pervasive solution.

I also think MUDE misses the mark with the conflict resolution workflow, which is depicted in the screenshot directly above. The Define Merge Strategy dialog occurs for individual developers when they try to publish changes back to the Master Repository. I would argue that the handling of conflicts should not be the developer’s job. Suppose I add the logical column % of Discount to a logical fact table as depicted above. If my change conflicts with a change from another developer a continent away, am I really in a position to be able to determine the appropriate conflict resolution at that point in time? I may not even know the other developer… or understand why we are both making changes to the same logical column. So regardless of whether conflicts arise, developers should be able to “publish” their changes to be resolved downstream by the source master. This source master role may be a part-time or full-time role… but this is the person whose job it is to resolve conflicts. So our SDLC solution needs to support the decoupling of multiuser conflict resolution from the development process.

In the next post, I’m going to take a look at the combination of MDS XML and Git. I’ll talk a little bit about Git, and why it’s superior to Subversion for our purposes. I’ll see if this combination can tick all the right boxes I described above.