In my article, Single package deployment in SQL Server Integration Services 2016, I covered the exciting single package deployment feature available in SQL Server 2016 via SQL Server Data Tools (SSDT) 2015. I think in the midst of the excitement, some people started confusing this new feature with the package deployment model. In this post, I try to clear out any confusion so people can be better informed before they join in the excitement.
Single package deployment was always supported in the package deployment model. This support did not just start with SSDT but it was the only deployment model support in BIDS (Business Intelligence Studio). The exciting part is that now the project deployment model in SSDT has begun supporting the deployment of a single package within a project instead of deploying the entire project. Prior to this, we were sitting with a situation of having to redeploy the entire project every time one made changes to selected packages.
Perhaps, the simplest way to explain why single package deployment is incomparable to the package deployment model is by the following:
Take for instance a new SSIS Catalog server – without any existing projects – as shown below:

Launch your SSDT 2015 project and deploy a single package i.e. PackageA in my example shown below.

You will soon realize that you cannot proceed with the deployment as the OK button is disabled. Instead, you are required to first create a project (by clicking the New Project… button) before you can deploy the single package.

Once you have created the project, the OK button becomes available again, thus you can proceed with deployment.

This works differently from the package deployment model which allows you to deploy a single package to SQL Server, file system, or, package store without firstly creating a project.

It’s that simple, folks!
Until next time, cheers.
Sifiso

CodeProject