OBIEE development, test and deployment
Michael Wilcke
process for OBIEE and wonder whether somebody else has already spent
some time on that...
Requirements are:
- several developers for rpd and web cat
- sound quality check *before* UAT, preferably regression
- UAT against a quality-system (Q-system) using productive data
- "web cat development" also by end user (in My Folder) on production
system (P-system)
Some things seem simple or obvious:
- use MUD for multi-developing rpd
- Developer checks out from master rpd on Q-system
- Each developer runs a local OBI system (D-system), developing
on his checked-out rpd in online mode (quick turn-around)
- after *testing* (see below) he merges back to master rpd on Q-
system
But ...
Q1: what about config management? does it make sense to put an rpd
under version control? the file or an UDML export (to have a chance to
diff)?
Q2: there are very few comments on MUD in the web, some indicating
problems (quote: "I'm not a fan of MUD"). Any REAL-LIFE experiences to
share? Does the merge really work?
Q3: Use WHAT for multi-developing web cats?
develop web cat on D-system?
if yes - merge D-web-cats into Q-web-cat with catalog manager? how
to detect and solve merge conflicts?
if no - on Q-system (i.e. after rpd-merge, somewhat late)?
if yes - merge Q-web-cat and P-web-cat with catalog
manager? how to detect and solve merge conflicts?
if no - on P-system (together with all these "end-user
developers")?
if yes - how to deal with big changes? turn down
the P-system for development (just some days)?
if no - you are kidding :-)
Q4: config management of web cats seems to be simple (just XML-files).
Any experience?
And last, but not least: Testing. I have no idea how to achieve
something like a professional level here
Q5: how to perform (unit) testing on D-system (goal:
prevent from merging bugs into Q)
(system) testing on Q-system?
(goal: provide sound quality for UAT)
test rpd only? web-cat only? rpd+web-cat together? test-cases in
test-dashboards?
testing dashboard prompts, drill-down, nav-links? automation?
regression?
This is my first entry in this group and I hope these are not too many
question marks for one discussion.
Michael
Andriy Yakushyn
1. To my opinion, I think it makes sense to store RPDs in some
versioning system, however, I doubt you'd be able to easily point
differences in those versions (even if you're going to use UDML
extracts). Also, you might want to back up an archive of your webcat
as well on a regular basis.
2. MUD can be a real pain. We've played with it, and after several
tries abandoned it for now. It sounds all great in theory, but 3-way-
merge doesn't always work intuitively - and there's still too many
opportunities for human mistake - especially overwriting someone
else's work. Right now, developers in different teams work on separate
RPDs, and then 1 person merges those pieces together - usually,
there're no problems, since we require full object separation
(starting from DB->connection pools->Physical Tables). It required
some planning to avoid doing duplicate work. It's not ideal, but it
works.
3. Matter of personal preference. But it seems as separation -
separation - separation works fine. Developers test locally and handle
everything to 1 person who does actual merging (using 2 catalog
managers). Deployment to PROD could be even copying physical webcat.
Again, Mark Rittman blogged about these issues in great detail,
including various scenarios (Users creating reports in UAT, users
creating reports directly in PROD, etc.) - let me know if you have
problem finding URL.
4. It's easy, but you need to keep an eye on consistency (could be a
different presentation server, different port, different location of
credentials file, etc.).
5. It depends on changes. You need to decide which changes require
full regression testing (if you change name of a column in a
presentation column and remove alias - which is a good practice, your
developers would need to iterate through all saved reports, in order
to "fix" them - not much fun) which can be checked on 1 report
(formatting for a certain column). Or whether you need to do something
in-between (BI Publisher reports' integrated into Dashboards, prompt
test). Most of the time though, you should be able to segment your
work as such to not to have to do full regression testing (unless
there're major changes in RPD).
je...@brewpalace.com
My reasons:
- Too many chefs in the kitchen causes things to break
- MUD simply doesn't work - it is far too buggy and unreliable
- Its better to have RPD architects who are full time on the RPD, not split with Reports and RPD. They can not only build greater tool expertise, but more importantly have a holistic view of the RPD and assess impacts to it that other will miss.
If you must have multiple RPD developers, perhaps split them to own their own set of facts and non-conformed dimensions. Conformed dimensions need to be split out somehow as by definition they are shared across multiple developer's fact tables.
Also, make sure you have an overall architect, one who is responsible for the RPD as a whole. Make sue they review designs of the other RPD developers and assess their impacts, perform code reviews, and ensure common objects (e.g., init blocks) are done correctly. Do not set it up as a democracy in other words.
Also, make sure you coordinate your releases, and by that I mean every few months not every two weeks. It is simply too difficult to have some config ready for production while other config is in dev or test. Again, MUD provides no benefit here.
Jeff M.
From: Michael Wilcke <michael...@gmail.com>
To: OBIEE Enterprise Methodology Group <obiee-enterpri...@googlegroups.com>
Sent: Wed, March 31, 2010 6:43:59 AM
Subject: [OBIEE EMG] OBIEE development, test and deployment