Migrating Objects from Dev to QA to Production?

[amanx]

Hello,

We are currently using 7.2.2

We are tyring to create an efficient method/protocol to migrate MS objects from Development to QA and then to Production.

Some of our concerns:

Dev envronnment has a lot of objects that are not ready for migration to QA. (Like wise for QA migrations to Production.) We need to be able to selectively pick the new and enhanced object we want to migrate.

Does any one have any experience with this? Ideas?

We've come up with a few things, but they've proved to be very tedious.

Thanks for your help..

 

[chael]

First and foremost: use Object Manager. Works fine in 7.2.2. OM allows for logging so that you can keep track of migrated objects, etc. but I am sure you were already aware of this.

As far as coming up with a system for migrating between stages...most migrations tend to be one way...moves typically occur from Dev -> QA -> to Prod. This model is typically fine, but often the dev environment tends to get messy...many extraneous objects, tests, etc. One recommendation is to occassionally clean the slate in Dev by replacing the entire dev MD with the projects in QA. Occassionally doing this keeps QA in synch with Dev, and will mean that moving one object from Dev to QA will not require other dependent attributes, facts, etc. to get moved over as well simply because they exist differently in QA.

I am curious as well to see what other user experiences with metadata management are. Object Manager is a must...using the Project Merge wizard is also recommended.

 

[paulmaric]

Chael is right, and you can use the Project Merge Wizard as a decent bulk OM mechanism, especially since you can create your own Project Merge XML to get exacly the objects you want moved with the resolution you want. I found there are extraneous (but necessary) object types that will be copied over with a merge, though, so be careful of this. These are things like attribute form types, and others, that there is no interface for OM'ing, so it just assumes you want them moved.

 

[nlim]

Moving dependent objects should be the correct behavior in any case, cos you don't want orphaned reports with incorrect references.

 

[amanx]

Thanks you every one for your input it has proved useful. I've only been using MS for about 3 months. Been challenging and this is the only user group I've found.

Well, back to the migration topic….

Currently we've got the following environment set up:
Dev, QA, UAT, Prod. All object migrate in that order as well.

I was thinking about using the following instead Dev1, Dev2, QA, UAT, Prod.

In this case we have Dev1, that would be used to build the objects - once they are complete they would be put in Dev2. Basically objects in Dev2 are ready to 'go' -> Unlike Dev1, which will be more like the assembly production line for the objects

Objects in Dev2 will sort of be like a storage warehouse of objects.

Using chael's suggestion we would have Dev1 and Dev2 routinely synchronized with QA.

I've thought about using two Dev environments in the event that multiple enhancement and migration requests were received simultaneously – to help reduce conflicts/miscues that may occur.

For Example we receive two requests at the exact same time:
(Filter A for Report A. Report A and filter A already reside in QA)

Migration request 1: Change filter definition to include June data.
Suppose this change needs to take effect next week.

Migration request 2: A metric was missing from Report A and needs to be
re-migrated to QA immediately.

I was thinking the developer can make both changes in Dev1 and then only migrate request 2 to Dev2. That way if another developer is given the sole responsibility of 'Migrating objects to QA', there would be no chance of a premature migration of Filter A.

This is a pretty simplistic example…just thinking that as our project grows how to avoid migrating objects to QA that are not ready or incomplete. I guess I'm trying to find a way to flag objects as 'ready to migrate' or 'not ready to migrate'.

What do you guys think? Unnecessary precautionary steps (having Dev1 and Dev2)?

Thanks for you input.

 

[mstrNate]

Hi Amanx,

Yes, I think Dev1 and Dev2 might be a bit of overkill. It's your environment of course, but I think three (or 4 in your case) levels should be good enough, at least that's been the scenario in most places I've been. You've got more to maintain with the extra dev area, 5 areas seems rather large to me.

If you have a couple changes to a report, you could just give those changes to one developer. That way you wouldn't have to worry about conflicts when you join the seperately developed objects together. For example, what if they develop the objects separately and they test out ok, but then you put them together at the next step in Dev2, and with both objects on the report, the report doesn't work anymore? Having one person develop them at a time would make sure the objects get tested with a bigger picture in mind.

HTH,

Nate

 

[chael]

I agree with mstrNate...keep it simple, consolidate your development down to one person developing per project. You can document all you want, but getting reports just right is an iterative process, best done by one developer so he/she knows what the left and right hands are doing.

I think 2 dev environs is overkill, but you know your business best...it is not atypical to have many smaller local instances of projects running on developers machines...these can collectively be considered Dev1, if you want.

One of the most important things to remember when dealing with many instances of projects is that it is typically best to duplicate projects rather than do a database backup and then restore the backup file. You cannot move Project A objects to an exact copy of Project A. If you duplicate through MicroStrategy, the metadata will be the same, but Project A becomes Project B with a distinct ID....it is then acceptable to move objects from A to B via Object Manager.

 

[nlim]

My only comment, also make sure you have some production-ready procedures in place.

1) Backups of all dbs are done by XXXX person, everyday at YYYY time
2) in the event of a server breakdown, follow these steps to recover:
i) call so and so at 1234567
ii) notify all users by sending an email with the following text "....."
iii) save current copy of md....
iv) recover from backup copy....
v) take snapshot of server when it crashed....
3) pocs for changes should flow throw these people ....