Friday, March 9, 2012

How can only certain objects (dimensions, cubes) be deployed?

How can only certain objects (dimensions, cubes) be deployed?

From Visual Studio I would like to deploy individual items like a dimension or cube without all of the changes in the other objects being deployed.

I don’t see any way to do that. Every time one thing gets deployed, all changes get deployed.

Visual Studio sends a Message Box Stating that the whole SSAS Database will be overwritten on the server and asks if you want to deploy or not.

We have multiple developers working and it has become a problem. We can’t deploy just those changes that are ready without overwriting the whole database.

I feel your pain...I have the same issues here (even though I'm the only developer on our BI apps). One possibility could be to have your developers work directly on the dev analysis server and add objects there. Then, you can use SSMS to individually process objects (dimensions, partitions, measure groups, etc). I'm also going to try deploying all my changes to a "staging" Analytics Database, which could be swapped out with the production DB when necessary.

It'd be great if there was a set of best-practices around the complete SSAS lifecycle.|||

While the underlying XMLA commands do support deploying single objects like a cube or dimension, it can get a bit difficult to manage due to the dependancy relationships between the various objects.

Probably a better approach with multiple developers would be to use a version control system. This way you could check-in your changes and do a "get latest" to make sure you are deploying the latest version of all the objects.

Although having said this, by remarkable coincidence I have been working on an add-in for Visual Studio that lets you deploy only the calculation script for a cube. It would probably be technically possible to extend this to deploy just a cube or dimension, but I am still concerned about the effect that this may have on dependant objects if you had multiple developers working on the same database. I still think it would be worth looking into using a version control system.

|||

We use Visual SourceSafe. The situation is as follows:

I have the Time dimension checked out and am making changes. Bob has the CashRecxeipts cube checked out and is making changes.

If I finish 1st and am ready to deploy the new Time dimension, it will invalidate all cubes that use the Time dimension. Bob will have to get the latest version of the Time dimension and fix the relatoinships for it in the CashReceipts cube before he deploys his changes.

If Bob deploys without getting the latest version of the Time dimension he will overwrite my changes.

Also, I have to modify all cubes that use the Time dimension and check their relationships to the Time dimension before I can deploy. I can't modify the CashReceipts cube because Bob has it checked out. I am at a standstill.

It is very difficult to coordinate with developers when we are in different cities.

|||

I don't see any easy answer to your question.

In your scenario, it might be possible to write something that would deploy just the altered time dimension and just the CashReceipts cube, but if you did this the CashReciepts cube would still be broken if it was not first adjusted to cater for the changes in the time dimension.

One approach that is sometimes employed (not with SSAS as far as I know, but the theory would still apply) is to have only one person (or process) that deploys to the server. They do a "get latest" from Source Safe, check that everything builds and then deploys, if anyone wants to get something new onto the server they have to check their changes in and let this person know. Ideally each developer should have their own local copy of the DB, preferrably with a small set of data so that they can process it quickly and test their changes before checking them in.

There are even tools that exist for platforms like .Net and Java, that will check the latest code out of the version control system when a new checkin is detected and build and deploy. I don't think any of these tools have hooks to SSAS, but most of them are fairly extensible. CruiseControl.Net http://ccnet.thoughtworks.com/ is one example, if you search for "Continuous Integration" you should be able to find others.

Mark Garner http://mgarner.wordpress.com/ has done some posts on his blog about applying these sorts of principles to Data Marts http://wordpress.com/tag/agile-data-warehouse/

|||

Darren,

Thanks for your suggestions and information on tools and procedures. They are good ideas and should prove helpful.

No comments:

Post a Comment