Best way of Change Management

[cognostechie]

I am contemplating which is considered a better way and what are the pros and cons of both:

1> Install Transformer on DEV, build the cube on DEV, make changes and once done, copy the Model, scripts and packages to PROD, then build the cube on PROD against the Production databases

2> Build the cube on DEV, save the cube on a NETWORK drive that will be used by DEV as well as PROD. In other words, do everything on DEV and just transfer the Cube package to PROD via the deployment process.

Any other way that you have used or prefer?

[Arsenal]

IMHO, a network drive will never have the same resources as a standalone app server will have. If you have a significant number of users, then traffic to the network drive will become a real issue and your report performance will suffer.

If you build and store the cube locally, then building can be helped by greater app server resources and local connection to the cube will translate to better access speed for reports. If you have multiple servers on Prod, that's even better because then you can store a copy of the cube (build it on the best server and copy it to the other servers as part of your macro) on each server which would truly translate to load balancing.

Depending upon the size, content etc. of the cube, the build might affect the performance of the app server during build time. This can be countered by either building thecube at night or very early in the morning. If the cube depends on a DB trigger but the time of the trigger will vary then you may considewr your options - live with temporary performance degradation but have a faster cube build time+faster access or build the cube elsewhere (network drive for example) and copy it to the app server so you get the benefit of local access at least.

Just my thoughts.

[cognostechie]

I think that makes sense. Thanks !