Incremental package deployment

Prior to SSIS 2012, packages needed to be deployed one by one. We were usually downloading all packages from the source control software, such as Team Foundation Server (TFS), Visual Source Safe, SVN, and so on. Once downloaded, packages were moved to their destination. At that time, the person who deployed the packages had the choice to overwrite or skip existing packages. Usually, they overwrote all the packages since they were using the source control.

For those who didn't use the source control, they had all the necessary flexibility to deploy what needed to be deployed. Usually, they were keeping a backup somewhere on a file share of all packages. The reason why they chose what to deploy was mainly because they had doubts about the consistency of the packages in the file share. They were simply not sure of the state of the packages because they were using a manual process to maintain their solution. The source control software helps a lot with this. We have the possibility to compare versions between packages committed in the source control, and when and who pushed the package, among other benefits.

Enter SSIS 2012 with Project Deployment. The only way to deploy a package was to deploy the entire project, and thus, all packages in it. If the source control was in place to manage the package code, this was barely an issue. But, not everybody is using the source control and Microsoft recognized it. With SSIS 2016, we can now deploy part of your project packages. You're not forced to deploy the entire project.