Related:
OBIEE Software Configuration Management by Mark Rittman
- Part 1 : Initial Deployment from DEV to PROD
- Part 2 : Subsequent Deployments from DEV to PROD
- Part 3 : Version Controlling the Project
OBIEE Enterprise Methodology Group Discussion
- OBIEE development, test and deployment
- Multiple RPDs/WebCats
Those deal with more of the software side of things. I want to explore the physical set up a little. I don't have the definitive answer, just thinking out loud perhaps.
The client is considering a ramp-up of development efforts (good thing). We were asked to think about an environment to allow parallel development. This is no easy task in OBIEE as the RPD can be a bottleneck.
While talking about it though, it sounded a lot like classic software development and source control. You pull down the code locally, fix/create/update it, and then merge that up into your trunk (subversion lingo anyway). You merge it up into a common repository.
What if you physically separated your environment? Here's my thinking:
- Find the common code (init blocks, connection pools, etc) shared by all subject areas. Especially relevant if setting some variables or something for security.
- Create virtual (or physical) machines with the full OBIEE environment (services, rpd, web cat) set up for each subject area and only that subject area. Of course this would include all components identified in step 1.
Pros
- Allows for parallel development
- Easier to identify changes
- Easier to import than merge?
- ????
- Separating RPD into sections, scary
- How do you handle physical tables shared across subject areas?
I don't know if this has merit or not, but I wanted to put it out there. Good or bad, I'm OK with. The goal is to give the client the most reasoned, researched, supportable analysis that I can.