Version And Environment Management Using OWB10g

One of our customers recently asked me about the best way to manage multiple environments when using OWB. The customer had a development environment, together with test, QA and of course production, and wanted to know how to set up their design and runtime repositories. Do we create separate design and runtime repositories for dev, test, QA and prod, do we have just one for all environments, or is the answer somewhere in between?

The situation is complicated a bit by the fact that OWB's architecture has changed slightly over the previous few versions. Up until OWB 9.0.3, you had a design repository to which your OWB client connected, and one or more OWB runtimes, which you installed into every schema you loaded data in to. With OWB 9.0.4 this changed in that you now have one runtime repository per target database, and this runtime repository contains all the packages, and stores all the load results, for use by all the target schemas in a database. More details on the new runtime architecture can be found in Architecture Whitepaper for Warehouse Builder 10g and Server-side component (runtime) in Oracle Warehouse Builder 10g on OTN.

In practice, we've found that different clients use different approaches to solve this problem. Some of them have a single design repository, with it's contents effectively being the most current view of the OWB project definition. This definition is then used to initially populate the dev warehouse environment, and after that it's used to populate the test and QA environments. Once everyone's happy that this is ok, it's then used to load up the production warehouse environment.

The problem with this is that the model within the design repository doesn't usually reflect what's actually deployed in test, QA and prod. One way around this is to make backup copies of the design repository (using the .MDL file export routine) after each deployment, and then load these up whenever required to see how the design repository looked when you last deployed to an environment. Another way to deal with this is to have separate design repositories for dev, test, QA and prod, and keep these in sync by exporting and importing modules between the environments using the .MDL file export facility. Yet another way is to use the snapshot facility in recent versions to store copies of the repository for later reference.

You'll be interested therefore to know that Oracle have recently posted a series of OWB casestudies, one of which is specifically about version and environment management using OWB. Entitled "Case Study 9: How Do I Manage Multiple Versions of my BI Implementation?" it discusses two scenarios where OWB is used to manage multiple target environments, such as dev, test, QA and prod. According to the article introduction:

"After a period of development and testing, one company implements its BI system in production. The Production version of the system typically changes as new features are incrementally implemented from Development, and as Production bugs are discovered and fixed. At the same time, the Development version of the system continues to evolve with new functionality. This company now has several individually changing versions of the system and faces a challenge familiar to all companies, regardless of how many BI environments they maintain: how to best manage changes in different versions of the system.

One version of this common scenario is depicted in Figure 9