We are in the process of upgrading our SQL server from 2008 to 2014 and separating the Database server from the file server. I changed my SSIS packages to have project parameters defined, which means that... when I deploy my project all 35 packages within my project get deployed. I would rather have the smallest unit of deployment to be the package. Should I revert back to the package deployment model and get rid of my project parameters? I fail to understand how two developers can work on two packages from the same project and only the 'tested' one needs to be deployed. Any insight to help me understand would be helpful. Thank you much.. SD
2 Answers
With the release of SQL Server 2016 and SSDT 2015 the issue of single package deployment is now a thing of the past. There is the new Deploy Package option (VS 2015) that comes up for deploying individual packages within a project deployment model.
Source -
http://www.sqlshack.com/single-package-deployment-in-sql-server-integration-services-2016/
Where as I know there are few differences in Project and package deployment.
Project uses parameters while Package uses Configurations files/tables. Project is located in an .ispac file and packages have .dtsx extensions whilePackages have .dtsx extensions. Project is deployed to integration service catalog while Packages are deployed to the MSDB or File. New environments in the SSIS catalog can be used with parameters while System environment variables can be used with configuration.