SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Development Lifecycle Deployment SSAS, SSRS, SSIS


Many companies have a very rigid development lifecycle for all products or solutions they develop.  Deploying to each of these environments (Development, UAT, and Production) can be a nightmare to maintain.  Luckily there is a great feature in Visual Studio called Solution Configurations, which will allows you to toggle between which environment you want to deploy changes to.

This feature should be already available by default in your Visual Studio but you may have never used it. 


As you can see it comes with several profiles that are created by default but you can create your own and configure them appropriately. 

By selecting a profile any changes that you make to properties of the project will be only seen for that profile.  For example, I could use the Debug profile and changed the properties of my Report Server project to point to the development Report Server.


When I switch to another profile like the Production profile it doesn’t know about the dev TargetServerURL change I made.  I can now point it to my production server which will give me the ability to toggle between deploying reporting to development and production.  Again you can create your own profile names and configure them however you want but the only properties that can be changed by toggling are the Property Page properties.

MSDN link for more info: http://msdn.microsoft.com/en-us/library/kwybya3w(VS.80).aspx

Devin Knight

Devin is a BI consultant at Pragmatic Works Consulting. Previously, he has tech edited the book Professional Microsoft SQL Server 2008 Integration Services and was an author in the book Knight's 24-Hour Trainer: Microsoft SQL Server 2008 Integration Services. Devin has spoken at past conferences like PASS and at several SQL Saturday events. He is a contributing member to the Business Intelligence Special Interest Group (SIG) for PASS as a leader in the SSIS Focus Group. Making his home in Jacksonville, FL, Devin is a participating member of the local users’ group (JSSUG).


Posted by Steve Jones on 18 February 2010

Very nice tip. Wasn't aware of that, but it's a good way to target different environments for deployment. However can you easily store off the deployment package in case you don't have network connectivity? Or for repeated deployment (do QA, then do production)?

Posted by knight_devin@hotmail.com on 18 February 2010

The solution configuration you create is saved within the solution so next time you open it any setting you did previously will still be available.  

Posted by Gordon Moll on 23 February 2010

I find it interesting that the tech world is satisfied with Microsoft's approach to development lifecycle.  Typically, a developer only has the ability to change code and deploy to the development environment.  After the new code has been validated in development, the code is copied to the UAT environment with no opportunity for changes by the developer.  This is called change control.  The same is then done from the UAT environment to production.

The deployment model of deploying code from a developer's space into development, then into UAT, and again into production (all by the developer via Visual Studio) allows the opportunity for different versions to be deployed into all 3 environments.

There are ways to enforce change control for SSIS and SSRS outside of Visual Studio.  I've not seen an elegant way for SSAS though.  Seems to me that there is room for improvement in this area.

Posted by VALEK on 25 February 2010

Configuration feature in BIDS is very limited and the usage of it may result confusion at the least and more serious things such as overwriting or processing wrong database.

This is why it is not used much, since the deployment to this or that server should be either scripted or carefully and manually attended.

Be careful guys


Leave a Comment

Please register or log in to leave a comment.