Going in Production - Expert Cube Development with SSAS Multidimensional Models - page 286

Making changes to a cube in production
The first problem we'll face once a cube has gone into production is how to
make changes to it without causing disruption to our users. In a development
environment, we can generally make any changes to a cube we like because we are
the only users of our cube. However, we need to be more careful when deploying
changes to a cube into production for two reasons:

• Some changes may result in cubes or dimensions becoming unprocessed.

For example, adding a new calculated measure to a cube doesn't require any
processing at all, but on the other hand, adding a new dimension means that
the cube will need a Full Process. If we have a lot of data in our cube, a Full
Process might take a long time, and our users will probably not want to have
to wait to run their queries while this happens.

• It's likely that our solution will not match the deployed version of the cube

in some important respects. We saw in Chapter 9 , Securing the Cube , that
roles may be added or updated on an Analysis Services database after it
has been deployed; similarly, we may be using different data sources in our
development environment compared to our production environment, and
as we'll see later on in this chapter, it's possible that the measure groups in
deployed cubes will contain extra, dynamically created partitions. When
we deploy a solution in SQL Server Data Tools, we have to deploy every
object in it - and if we overwrite the roles, data sources, or partitions on the
production server, we will end up denying access to users and dropping data
from the cube.

One method we definitely do not want to use for deploying changes to a cube in
production is to edit the cube directly in Online mode. Although this might seem a
quick and easy option, it will of course mean we are bypassing any source control
we are using. For the same reason, we don't recommend making changes by running
XMLA statements to update an object's definition.

There are two safe and commonly-used techniques for deploying changes to a
production environment:

• We can use Visual Studio's project configurations feature, as detailed in this
blog entry: http://tinyurl.com/gregprojconfig . For a single project,
this allows us to configure different property settings, such as the connection
strings used in Data Sources, for different build types like Development or
Production. This is a very powerful feature, but it still does not solve the
problem of overwriting roles or partitions on the production server.