Lempster (1/30/2014)
Andrew Notarian (1/30/2014)
In that case I think you are not going to find too many people who have used that. I don't think most people deploy the whole solution to other environments.Interesting philosphy Andrew. Presumably most people would want to test thier ETL process (SSIS-based) and Cube processing/browsing in at least one environment prior to Production, so are you saying that each composite part would be deployed piecemeal, i.e. create and populate the relational DWH database as one step, deploy & test the ETL packages as another and then deploy & test the Cube as a third step?
If one is developing using SSDT-BI inside the Visual Studio shell (or the full-blown Visual Studio), one has the option to Deploy the entire Solution. What I am seeking is a method by which people without access to Visual Studio and SSDT-BI can do that. Maybe I should just seek the Holy Grail instead!
I came to BI work from a development background. I treat SSIS and SSAS projects as if they were ASP.NET projects. In ASP.NET, you build your project and only deploy the DLLs and ASPX pages to the server. The source code (i.e. the solution) does not get deployed. For SSIS, we build the project and only the DTSX files get deployed to the server.
SSAS is more analogous to traditional database development. You pass off your DDL to the DBA who then reviews and runs it to support your changes to the application. For SSAS, we use the Deployment Wizard to generate XMLA instead of T-SQL.
The data warehouse piece would just be however you deal with regular old OLTP database in your company.
With the data warehouse structure up to date, your new SSIS ETL in place and your latest OLAP cube structure ready to go, you should be able to run your SSIS packages to load up your data warehouse properly and process your cube. If that works in QA, then you have some level of confidence that you can repeat those deployment steps in Production with success.
Using that approach you would not really want to have your solutions,projects, (i.e. your source code) on a server, be it Test, QA, Stage or Production.
At this exact moment I am working on the best way to deal with configuration changes from environment to environment so that the compiled ETL code (i.e. the DTSX files) can remain the same with only the config changes. That's also like ASP development where you ignore your web.config file when deploying new compiled .NET code.