Monday, February 8, 2010

OBIEE and Source Control?

One very difficult aspect of using OBIEE (or APEX for that matter) is that it doesn't lend itself very well to source control.

There is one RPD (metadata) file in use at any given time. Changes to this environment will affect anyone using or developing on the presentation server layer (Dashboards/Answers/etc).

For the web catalog (Answers/Dashboards/Prompts/etc) you can make changes, but again, it will affect anyone who is also using the tool. If you want to tweak a report that has prompts or filters, you need to save everything off to your own folder in order to work on it or risk colliding with others or worse, messing up the report beyond repair (also known as FUBAR).

Developers usually need to break things to fix them and giving them an environment where they can do this (also known as tinkering), without repercussions, should be high on the list of must-haves.

Inspired by a meeting I attended last week and Jake's recent welcoming of VirtualBox into the Oracle fold, I decided to think (yikes) my way through a possible solution.

After the meeting last week, I was convinced I could build an environment using subversion as the source control tool. Tie that in with Jira, Fisheye and ultimately Bamboo and you'd have a pretty sweet environment to work in. How to do it though?

1. Set up source control. SVN is free and runs on Linux. Free.
2. Convince a multitude of developers to install and configure OBIEE on their own workstations. Yeah...not so sure about that. I accidentally said in that meeting, "I don't know a single, good developer who doesn't have a local install of Oracle (the database)" May have been just a tad hyperbolic...I like to tinker and appreciate those environments which allow me to do so. Having a local sandbox has been indispensable for me.
3. Not sure where or what 3 is. That's where I got hung up...until reading Jake's post.

How about this then?

1. No subversion (for the time being).
2. Virtualize the development environment.
3. Hand out the VDIs to the developers, and let them run with it. When they make changes, they can promote them through the usual channels. Once those changes are accepted/merged with the development environment, a new snapshot is taken and distributed.

Having the snapshot of dev is the key I think. Those who don't like to tinker, who just like to get their job done, won't have to worry about configuring their environment. They'll just fire up the VM and do their work. For those that do like to tinker, they can fiddle with the VM as much as they want without fear of breaking things for everyone else. If they need a fresh start, just get the original VDI and go crazy again.

This hasn't been completely thought at (if you couldn't tell). I haven't considered passwords or other such sensitive data. It sounds good in my head though. What's the worst that could happen?

3 comments:

rnm1978 said...

hey chet,

Check out Mark Rittman's article on source controlling OBIEE

If you want to get funky then look into UDML (both nqudmlgen and nqxudmlgen), and admintool.exe /command. There's various blogs about them, and a very good paper by Andreas Nobbmann about UDML.
All dodgy (as in, not supported) but might flick your switch :)

Would be interested how you get on with using virtual machines. Here we use SVN. You have to get away from the idea of being able to use source control on a very granular level, and work more with the BI environment (db schema, RPD, web cat, etc etc) in a point in time state. And/or look into MUD for OBIEE.

cheers, RNM

Mark Rittman said...

Chet,

This article is an updated version of the one that RNM links to:

http://www.rittmanmead.com/2009/12/02/obiee-software-configuration-management-part-3-version-controlling-the-project/

Basically it's more realistic about what's safe to upload to SVN. The problem is that you can't really extract parts of the RPD and upload (then diff, merge etc) in SVN, all you can safely upload is the RPD.

Same goes for the webcat - the only safe way to version it is to zip up the whole webcat (or use the archive feature in the Catalog Manager) and upload it as a single object, as uploading individual files from the webcat filesystem will eventually introduce permission corruptions.

regards

MArk

oraclenerd said...

Mark & RNM,

Have either of you played around with Virtual Machines?

You both noted the concerns I have with subversion....more than anything though, it would allow an Administrator the ability to see what files did change in a given migration, which might be helpful. We have experienced problems specific to missing filters or prompts (and perhaps others, I'm not entirely clear) in regards to the web cat. Using a tool like subversion to see what did change might help to alleviate that.

As far as the RPD goes, I don't want to do anything that is unsupported. Not sure if the above scenario would help much finding "what changed?"