Home Dashboard Directory Help
Search

[SSIS] Collect all deployment-specific properties into a single file by Jamie Thomson


Status: 

Closed
 as Won't Fix Help for as Won't Fix


12
0
Sign in
to vote
Type: Suggestion
ID: 740059
Opened: 5/1/2012 9:03:36 AM
Access Restriction: Public
0
Workaround(s)
view

Description

ISPac files are a great step forward in SSIS2012 though that's not to say they couldn't be improved further. Every time we have to deploy a .ispac file we have to supply some parameters such as target server & folder; this is fine, but it could be better.

The SSDT team used to (when they were VS2010 Database Projects) follow a similar model as SSIS today where you had to supply values for individual properties but in SSDT 2012 they have improved that with Publish Profile files. Essentially a Publish Profile file wraps all of the deployment specific “stuff” so that all you need to deploy a SSDT project is the build output (i.e. a .dacpac file – analogous to a SSIS .ispac file) and a Publish Profile (i.e. .publish) file:

>sqlpackage.exe /sf:$(PATH)\MyDB.dacpac /pr:$(PATH)\DEV_environment.publish

I like Publish Profile files for a number of reasons:
•    You can define a .publish file for each environment and dynamically call the correct one based on the environment that you are deploying to
•    You can double-click on a .publish file in the IDE and it will provide a GUI that enables ease of deployment
•    They abstract all of the deployment detritus into a single file in your solution and therefore become artefacts that are maintained by a developer rather than an administrator (this is a very good thing)

It would be nice to have something similar for SSIS (and SSAS & SSRS come to that) so that we could do something like this:

>ispackage.exe /sf:$(PATH)\MySsisProject.ispac /pr:$(PATH)\DEV_environment.publish

The .publish file would define:
-Target SSIS server
-Target folder on the SSIS server
-Server defaults for all project & package parameters
-Possibly other things that I haven't thought of

I hope that makes some sort of sense!
Details
Sign in to post a comment.
Posted by Microsoft on 7/12/2012 at 2:23 AM
Hi Jamie,

We're going to resolve this issue as "Won't Fix". Although this feature is something we would also like to have, the scope and impact of this issue doesn't meet our criteria at this point.
We cannot say authoritatively that we will never implement this functionality, but it is not on our roadmap (short term or otherwise) at the moment, and were it to get onto the roadmap it would be competing with many other features for priority.
Thank you for your feedback. If you have more concerns, we're glad to hear from you.
Sign in to post a workaround.