Home Forums Data Warehousing Integration Services Package or Project deployment RE: Package or Project deployment<!-- 864 --><!-- 864 -->

  • August 21, 2014 at 11:57 pm

    #1740083

    pcd_au (8/21/2014)

    My experience is more with SQL2008R2 SSIS than SQL2012 SSIS, and I'm struggling to see the benefit of the Project deployment.

    The solution I'm working on requires reading source data from over 250 tables and performing a straight dump into a 'landing' environment, from there the new data if shuffled into a 'difference' database, from where it is transformed and combined with other tables into a 'staging' database and then into a Data Vault structure. To ensure sufficient throughput we spawn via CMD a package multiple time passing parameters on which tables to process. It seems to me that with the Project deployment approach, the SSIS server requires SQL to also be installed, and logging is performed into the SSISDB. Using Project deployment can I have a central server for logging and holding the packages? Do I lose any scaleout capability if we go with Project deployment?

    It seems to me that much has been lost with the Project deployment. With Package deployment I can run packages on multiple servers by reading from a common share. With Project deployment I'm unable to spawn multiple instances via CMD. Am I missing something? I want to avoid having to develop in excess of 1000 packages (data flows), currently we have 6 packages and a bunch of XML files that contain the source / destination information.

    Have others made the switch to Project deployments and is it worth the effort, or should I stick with Package deployments?

    Interesting solution architecture. How many SSIS servers are we talking about here, just for interest? Do you have centralised logging of package executions?

    I've been using the project deployment model since 2012 came out. Initially, it took some getting used to, but now I much prefer that all packages in a project are treated together, rather than in isolation and can share connections and parameters. ISPac deployments mean that you always know exactly which version of a package is deployed.

    Your solution sounds so well engineered (and, at six packages, very manageable) that you should stick with what works and maybe start 'trying out' the project deployment model for any new projects.

    If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.