Analysis services project lifecycle - data-warehouse

Question

Is there a standard via which one should start an analysis services project? Out situation is that we work locally on our machines, and the relational DB is out of our domain - and the server that analysis services DB will eventually sit on is out of our domain. So, I have a bunch of questions:
Where do you set up the Star schema DB (as the source of the OLAP project)? Is it on a separate server somewhere? And then how do you have a dev star schema db, vs your production star schema DB?
When you create a new Anaylsis Project on your visual studio, where should it connect to (dev star schema? prod star schema?)
Analysis services only supports windows authentication, so how do you get around this if your local computer and the dev analysis services is not on the same server?
When doing ETL work (on SSIS) which DB do you connect to? (dev, I assume) - but then how do you deploy to production?
What about down the line if you need to make changes - how does that process work?
I apologise for haphazard questions, but I'm not really sure where to start, so if anyone has a process from start to finish that is a standard, please let me know.. thanks!

Answer 1

For this one SSAS project that I recently set up, here is what I did:
I have a development PC and a server. Both in the same domain. The development PC is used to edit the VS project. The server is used to host the trial staging / star schema DB, real staging DB, SSAS development cube, and SSAS production cubes.
During development, I use the trial staging DB to test ETL, and deploy to the SSAS development cube.
To build the real cube, I switch the data source to point to the real staging DB, and deploy to a new SSAS cube. Old production cubes are left unchanged so users can still access them while I deploy the new cube. After the new cube is deployed, I will announce the availability of the new cube, and then I can delete the old one. BTW I do this monthly.
If your SSAS server is not in the same domain, you can create an SSAS DB backup, and restore it in that remote server.
To enable Visual Studio to access SSAS server, I had to run visual studio as administrator (right click VS shortcut, 'run as...'). Or you can open the SSAS server with SSMS on the server, then put your active directory user as member of administrator group.

Answer 2

It sounds like your main problem is that you don't have direct access to the production environment/domain and you're not sure how to deploy your SSAS and SSIS work.
In both cases you'll want to develop against the development database, which is hopefully a copy of the production database.
In SSIS, you will create Connection Managers that use connection strings pointing to your development environment. Add a package configuration file to give access to package properties, like the connection string. There are other ways to manage configuration information, but a config file is the mos straightforward. When you build the project with the Create Deployment Utility option enabled, the config file and a .manifest file will be created. Together with your package(s), these files can be run on the target server to install and configure the project outside the development environment.
Similarly, SSAS has a deployment utility. There are several ways to get an SSAS project deployed to a production environment. See: Deploying an Analysis Services Database into the Production Environment for one overview of the options. Note that data sources in your project can be manually modified by an administrator by connecting to the Analysis Server database in SSMS after deployment.
Changes in SSIS are generally handled by deploying updated packages. With SSAS, changes can be scripted or the entire database can be redeployed. The approach I would take would depend on the size and complexity of the SSAS database and what is changing.