Everywhere I go, the sentiment is the same: the development lifecycle is hard in OBIEE. This sentiment rarely surfaces in the first implementation, but rather creeps-in over time, eventually whacking you upside the head with a baseball bat. You groan, moan, whine, curse, and start throwing things, but it doesn’t change reality. Then you start to look for options and…crickets. The nighttime silence of bugs chirping washes over you and you resign yourself to suffering a slow, painful death in the Great Pit of Carkoon, the resting place of the famous Sarlacc.
OK, so maybe that’s a little strong. Maybe it’s not quite that bad. Maybe. But how did we get here? What is it we are lacking? In my opinion, every development environment should have the following:
- A working area for each developer
- Source control for everyone developing
- Branch-based development, with automatic merging of selected features into a fully-functional release
- Automatic regression testing of each and every new feature as part of the development process, before migration to QA
- Environment-specific build processes that automatically generate and deploy artifacts to each environment
To complicate things, OBIEE has a single metadata repository file. Allowing multiple developers simultaneous access to that file requires either live editing of the Dev environment server RPD file (generally a no-no), or developers working on their own version of the file in a local environment. We’ll come back to live Dev environment editing in a moment, but for local editing, each developer needs a full instance of OBIEE to develop their own local RPD. Why, you ask? Why not just a version of the Admin tool? Because any RPD developer will tell you that it’s really hard to develop a properly working RPD without the ability to unit test it against the BI Server.
We’ve established that developers need their own full OBIEE instances, but how do their local changes merge with the Dev environment RPD? How do we make sure each developer’s edits don’t collide with another developer? How do we keep a running history of what each developer did? Coming back to those live Dev environment editors I mentioned before…how do we keep a record of that they did? Now, OBIEE has a built-in check-out/merge-in process called MUD, but anyone who has tried it will tell you the process is very cumbersome, very manual, and is fraught with issues. OBIEE also has limited support for working with a source control system, but leaves it up to you to figure out your process for how to use it and doesn’t allow you to cherry-pick features to include in any given release.
If you manage to leap the hurdle of developing a process for OBIEE to work with your source control system, what then? Maybe you have the ability to automatically merge your code branches based on what looks like good code, but how do you know? Can you automatically test it? Where do you test it? Do you test the merged RPD of work from five developers on your Development environment, where report developers are developing reports? If you do, how do you get the RPD file there? Manually upload the file into Enterprise Manager and manually stop/start the services? Yawn…wake me up when you’re done.
But there’s a better way. Introducing Checkmate from Red Pill Analytics: a product, process, and service for doing all of this automatically. In fact, the name is a hybrid of “check-in” and “automate”, two key principles for how Checkmate operates. Let’s walk through how it works.
- Developers develop in their own full stack OBIEE instances. We prefer cloud instances we host and automatically spin-up/down for you as needed, but we can help you setup an on-premise model, too.
- Developers check-in/out of Git or Github, with developers working on their own feature branches for whatever feature they are building. To do that, we render the RPD as a folder of XML files and developers copy down a branch version before starting. The Catalog is already a folder of XML files, and can be included/excluded in the process as desired. You can use our Github account, register your own, or use your own on-premise Git.
- As developers check-in their work, their temporary instance goes away until another is needed again to minimize cloud usage costs (or can remain permanent if you choose). Meanwhile, the work developed on each branch is automatically merged as desired and reconciled with the develop master version using standard Github functionality.
- Once the RPD code is merged and reconciled, a new RPD is automatically generated and deployed to a temporary OBIEE instance (again, we prefer cloud) that is created on-the-fly purely for regression testing this new RPD. As the server is launched and the RPD deployed, tests are copied to the server and executed automatically, with failed tests generating notifications. This is all accomplished using a continous integration (CI) service and a lot of code from Red Pill Analytics. We’ll host that service for you, or show you how to run it yourself.
- Once the RPD passes the regression tests, or you exclude failed features from the release, the CI service terminates the temporary OBIEE instance, packages the final RPD (and Catalog if desired), and deploys it to one or more OBIEE instances and/or source control systems of your choice. If you use Red Pill Analytics’ cloud service and you don’t want to give us VPN access to your servers, we can upload the files to an SFTP location or similar for deployment on-premise (yeah, we can automate that, too).
If that weren’t enough, we can integrate this with your JIRA system or provide access to a hosted version of JIRA which will allow you to plan your releases, assign your development tasks, link the code in Github to the task, and package the releases.
Wow…problem solved. Why didn’t someone think of this sooner? It all sounds so easy. It’s the sound of the crickets fading and your developers cranking away like a well-oiled engine, chugging down the track. If you like that sound and want to see a demo, email us at “info @ redpillanalytics.com” for more information.
