Best practices for a microstrategy workflow -

we team of 5 people working microstrategy. share every role, have no worklfow.

everybody may build or change attributes , change schema. leads reports not working. furthermore, there no "good" documentation. tried establish documentation sharepoint, there had no workflow.

originally, had old project every report attributes constructed newly. did not reuse existing schema object.

hence, started new project. realized due lack of understanding , lack of workflow make , made lot of mistakes. feel understand things better (parent child), workflow still horrible.

we have development project , lice project, way working now, have lot of problems. particularly, missing version control system killing us. perform changes , forget did. hence, have use backups, destroying useful work on given day

so best practices to: * deploy new attributes, facts , reports * ensure old reports work after constructing new attributes , facts * improve documentation * attributes defined on fact tables , parent-child relationships

any appreciated

microstrategy development in team environment, deploying development live, can challenging. rightly point out, lack of version control, , unknown interdependencies between objects can cause untold problems. there's no 1 right answer question, suggest following:

use tools provided microstrategy. when you're deploying 1 project another, don't drag , drop in object manager, create package. when deploy package, make sure choose create undo package, can rollback changes if encounter problems.

on note, try catch these problems in advance. running integrity manager before , after deployment, if it's generate sql reports, point out if you've broken anything. on note:

create third environment/project. call test/release control, whatever prefer. here can test packages created in object manager, ensure have desired effect, , don't break anything. in effect, dry run deployment live. environment should regularly refreshed live (via project duplication), make sure doesn't in unexpected state (as result of broken object manager package import example).

over , above that, can offer organisational advice. it's not uncommon 1 person take responsibility schema objects (i.e. facts, attributes, transformations) developers don't undo each other's changes. if have large project, these objects split functional areas, , individuals assigned.

documentation tricky, put as possible object descriptions. has advantage of being visible in web interface (via tooltips), , included in automated project documentation, should choose generate that. there change log functionality each object, in experience, logs not completed developers, saving happens frequently. still, if can people populate that, you'd have head start on understanding change in project.

to summarise:

• use object manager packages deploy changes
• test changes integrity manager, catch issues possible
• use release control project/environment, you're not catching issues in production environment
• assign responsibility schema objects specific person or persons possible.