No. No you cannot. In SQL Server 2012, you will always deploy the entire .ispac file to the Catalog.
I’ve received this question a number of times in the past couple of weeks. It’s actually a feature we considered, and one that I (initially) argued for, as I know it is a common practice with SSIS solutions built for SQL Server 2005 and 2008. However, I was quickly convinced that the scenarios that require single package, or incremental deployment of a project can be solved using team development best practices and procedures. The central one being source control management of your SSIS packages.
Let’s compare developing an SSIS solution to developing a C#/.NET application.
- A package (.dtsx) can be thought of a source code file (.cs)
- The project (.ispac) can be thought of as the binary the source code compiles into (.exe)
If you have a team of developers working on the application, you would not do the following:
- Place the source code in a common directory which all developers work on simultaneously
- Update individual source files without recompiling the project binary
- Commit partial changes to one source file when it could break code in other source files
- Build and deploy the project to a test/integration/production environment when you are unsure whether the changes to other parts of the code made by other developers are complete
(Ok, maybe would not is too strong – I’ve definitely seen all of the above done before . How about we use should not instead?)
When I ask for details about the scenarios that people require single package updates for, it typically turns out that they are doing one or more of these “should not” things in their environments. If all of these things are red flags for application developers, then why do people do them with SSIS solutions?
I described some ideas I had for SSIS branching strategies when you’re using source control a while back. I’d like to add the following high level recommendations to that post:
- If you have a team of developers working on SSIS packages, you should put you SSIS packages in source control
- Developers should not commit changes until they are complete, or in at least in a reasonable state where the project is in a working state
- If you have developer working on a very large change that could potentially break things (or one you want to do in multiple steps), do the work on a sub-branch to minimize impact to the rest of the team
- Builds that get deployed to test/integration/production environments come from stable branches, not from the development branch
Now, there are probably cases where single package updates for an SSIS project deployment can come in handy (even when you’re using source control, producing regular builds off the integration branches, etc). I just haven’t been able to think of any. If you have one of these scenarios, I’d really like to hear it – either via Connect, or by posting here (or ideally, both). So far the customers I’ve worked with found that these deployment requirements went away once they started adopting some of these application development lifecycle best practices… but I’m always happy to be proved wrong!
