views:

1501

answers:

2

Scenario:

  • Production servers are running SQL Server 2008 in the domain myDomain.com
  • Dev/test/stage servers are running SQL Server 2008 in the domain dev-myDomain.com
  • Actual dev work done on local running SQL Server 2008 source controlled using SourceSafe

First of all, does this setup/environment make sense? And, what are some good ways of deploying projects including SSAS, SSIS, SSRS from local to the dev servers and finally into live?

Is including the output (compiled) files in SourceSafe and deploying from there good practice? If it is any ideas?

Or, is going straight from Visual Studio without having the output in SoureSafe better?

Thanks.

A: 

Visual Studio has configurations you can set up in order to deploy objects to different servers.

You can also use utilities to copy some around:

DTUTIL for SSIS - delivered with SSIS

RSScripter for SSRS - third party free tool, which is very useful

I would think you would use the deploy tool in Visual Studio for SSAS, as it needs to populate the model. I am just getting started with SSAS, so there may be other tools.

Sam
Thanks for the reply Sam. The part that I've been having trouble wtih is going cross domains. Example: deploying an SSAS database to a server in a different domain in Visual Studio.
Ali_Abadani
What error do you get? Are there domain trusts set up?
Sam
I am getting the error: Cannot connect to server. Make sure the server is running. Would I need to setup trust relationships? How? :)
Ali_Abadani
You might try asking at serverfault.com - I'm not really a windows domain admin type, so wouldn't want to steer you wrong.
Sam
A: 

We rely heavily on the use of variables for the items we want to change in differnt configurations and then config files (one each for Dev, QA, Staging, Prod). All SSIS packages and config files are in Source Save.

HLGEM
Where would I be able to find more info on using variables and config files?
Ali_Abadani
http://msdn.microsoft.com/en-us/library/cc895212.aspx . We use an xml file with the server\instancename and then store variables in a sql table in that instance. It's pretty slick!
Sam