Multi
user development using SVN in OBIEE 11.1.1.6
To involve several consultants
working on the same OBIEE repository. To cover this necessity OBIEE admin tool
offered the Multi User Development option (MUD) .
However, since the release 11.1.1.6
there is a new option available to achieve similar functionality and allow
teams of OBIEE developers to work concurrently on the same repository. It’s
based on the use of a source versioning control tool to track the new
developments and highlights the conflicts that might arise.
Apart from being able to use this
way to manage our OBIEE repository, this is not a replacement of the old MUD
option as each one of these approaches has its unique pros and cons.
In this article I explain how you
can have your dev team working on the same RPD using subversion instead of the
MUD approach and also what features we gain and lose along the way.
A review on the MUD option
In order to understand the benefits
and drawbacks of the new source control approach, we are going to review how
the old MUD option works.
Basically, behind the stage, admin
tool uses the merge and compare capabilities to enable multiple developers to
work on subsets of the main RPD called projects.
Each of these projects is then
merged and published back to the master repository that is shared on a network
location available to the developers. The projects however, should be
created beforehand by a MUD administrator that might be one of the developers
or a project owner.
Working with MUD has the following
advantages:
- Enhances the organizations of big
repositories into different projects
- It “works” out of the box
- It “works” out of the box
On the other hand, after several
projects using MUD we found some disadvantages too:
- Difficult set up, complex to
understand by new developers
- Working with shared dimensions between projects is cumbersome
- Sharing the RPD over the network is limited when teams are not in the same LAN
- Working with shared dimensions between projects is cumbersome
- Sharing the RPD over the network is limited when teams are not in the same LAN
Now let’s see how we can make use of
the new source version option to enable our dev team to work on the same RPD
without using the MUD option.
Multi user development over source
control
Before 11.1.1.6.0, the repository
has always been treated as one single (and rather big) binary file with
extension RPD. However, since this release, we have the possibility of managing
the repository as a set of XML files. This means that each one of the
first-class objects of the RPD (as presentation tables, hierarchies, physical
tables…) is no longer part of one big file, but rather a XML text file on its
own. A repository treated this way is in MDS XML format.
Once the repository is in this MDS
XML format, we can start source controlling the individual XML files as they
are text based and no longer binary. To start working in this way, we are
going to need third party tools and some set up. We usually recommend
subversion (svn) as the source control engine, particularly VisualSVN for the
server side and Tortoise-SVN as the client.
In addition to these third party tools, make sure that your OBIEE instance is running 11.1.1.6.0 or higher, and that you have close at hand the SVN configuration file that you will find here:
$OBIEE_HOME/instances/instance1/config/OracleBIServerComponent/coreapplication_obis1/scm-conf-svn.template.xml
As part of the one-time set up,
you’ll have to install the VisualSVN server and create your SVN repository with
the contents of the RPD file on MDS XML format.
This would be the same task as
putting the RPD on a shared network location when using MUD. Notice however
that when using SVN we don’t need to create separate projects.
After that, each one of the developers
needs to install the Tortoise-SVN client on their development machines and
checkout for the first time the master repository. This operation will transfer
all the XML files to their workstations so they can open the repository using
the new MDS-XML option.
The OBIEE Admin tool will allow you to select between the Standalone or Use Source Control options. Pick the second one and browse for the XML control file we mentioned before. After doing that you can go and start working under source control.
This step will be the equivalent of
setting up the MUD options on each one of the development workstations. One of
the advantages of MUD against the SVN option is that everything is built out of
the box and you don’t need any third party tools or software. It’s also worth
to say that the admin tool will work with any source control engine, not only
SVN.
So, what is it happening under the
covers here? The admin tool is opening the local working copy of the RPD that
is stored as MDS XML on your hard drive. This means that when you add or modify
objects in the repository and then save, you are just adding or modifying local
files. On other words, admin tool won’t commit your changes to the master
repository on the remote SVN repository; you’ll have to do it by yourself using
the Tortoise-SVN client using the commit option.
It will be then, after committing
your changes, when subversion will update the master remote repository and
identify possible conflicts with modifications that other developers might have
done. After that, you might want to update your local working copy to retrieve
the latest changes from everyone else.
This methodology allows several
developers to work in the same repository without worrying about overwrite
other’s changes as the subversion engine takes care of everything.
As usual, in case of conflicts, the tortoise-SVN client will ask us to resolve it by choosing whose change is the correct one or allowing us to merge both changes in the same file. This resembles the way that MUD identifies and resolves changes.
Here in ClearPeaks, we’ve been
testing this new approach to allow our consultant teams to work on the same
repository. The experience overall has been positive and successful; however
I’d like to address some challenges that we found along the way.
Thoughts after using SVN multi user
development
Maybe the best improvement that we
noticed when using the SVN approach is that we didn’t have to setup the
cumbersome MUD structure in terms of projects and network administration for
the shared repository. It’s more familiar to us, as software engineers, to work
with the well-known SVN repository structure and also to install the VisualSVN
server or the tortoise-SVN clients.
Also we found these additional major
improvements:
- Having the remote repository on a
VisualSVN server allowed us to access the RPD contents via https easily and
secure from different countries.
- The ability to create branches that SVN offers was really helpful to develop new requirements once the main project was deployed.
- The ability to create branches that SVN offers was really helpful to develop new requirements once the main project was deployed.
On the other hand, we found several
issues when using it:
- The parent-child hierarchies cause
the consistency check to fail. Hopefully this will get fixed soon by Oracle
- For big repositories it takes longer time to load the repository into the admin tool (our latest RPD took around 5 minutes to load in MDS XML format while taking just 10 seconds on offline mode)
- In case of conflicts it’s really hard to read through the XML source files to know what is going on. In this matter MUD is better as it will show you exactly which object changed and how.
- For big repositories it takes longer time to load the repository into the admin tool (our latest RPD took around 5 minutes to load in MDS XML format while taking just 10 seconds on offline mode)
- In case of conflicts it’s really hard to read through the XML source files to know what is going on. In this matter MUD is better as it will show you exactly which object changed and how.
In this article we saw another
effective approach to allow multiple developers to work concurrently on the
same repository using subversion as the version control system instead of the
MUD option.
