It's been a while since I last put up any substantial post so I thought maybe it was time to leave you with a brain dump of what I've (been attempting to) achieved over the past month.
Two major things stand out;
1. MUDE - Multi User Development Environment.
2. Integration with SVN Subversion.
The first was a no-brainer really, a few too many developers in the repository at once, lots of half finished code, the nightmare of promoting the repository to production based on what was complete or mostly complete. Definately time for MUDE.
For those of you unaware of MUDE and what it is, not many I'm sure, it is a method of segregating the repository into various projects, where each project is self contained and has all the component parts required to function. The projects can be checked out to a local install by developers where they work, in isolation, before merging their changes back into a central repository.
MUDE
To setup MUDE you need three things; a bi server, a shared directory on that server and a full local install of OBIEE.
On the server create a shared directory and ensure that all your users have sufficient priveleges to merge changes back.
The MUD Administrator then copies in the Repository required and this will become the MUD master against which all changes are published.
The repository is opened offline and divided into projects - again by the MUD Administrator.
On the client side the users open the OBIEE administration tool and in the Tools --> Options --> Multiuser Tab, point the where the MUD master shared directory (\\server\muddir) is and describe the environment (eg DEV Machine)
When a developer wants to work they will start the OBIEE administration tool on their local installation. From the File menu they will then select Multiuser and then checkout. Select the project, as setup by the MUD Administrator, on which you want to work and open.
The local repository consists of only those details required to make the top level components in the repository work. The project may not have specified the physical layer to include and this will be added at checkout by the MUD process.
The developer, using their local install, will make changes and test outputs against their local answers queries for that project.
Once changes are made the operator has several options;
1. Discard changes - revert to how things were.
2. Refresh subset - pick up any changes in the master MUD repository that have occured since the checkout, that affect this project.
3. Compare to original - show what has changed.
4. Publish to Network - promote changes back to the MUD Master repository.
When you publish back to the MUD Master repository, a merge takes place and if conflicts arise, you need to resolve them by selecting what goes through for publication.
The MUD Master repository will then be uploaded through EM and changes promoted up through your environments.
Just bear in mind the following;
You may require named user plus licensing to be financially viable
MUD is more complex than online development, but makes sense when you know how it works
MUD Administrator divides main repository into projects; self-contained RPD subsets
Master repository is then published to a network share
Projects are then worked on independently, and then merged back into the master RPD
Uses the repository compare and merge features under the covers
Works best when each developer has a full OBIEE “Sandbox” environment to develop with and unit test their work License considerations
Integration with SVN follows.
