Since SSIS does not like being merged nicely I was wondering how to have a big SSIS package split up. With the idea of having multiple devs working on this simultaneously, and a minimal chance of having merge conflicts.

In SSIS 2016 I found these options:

  • package parts, but apparently they don't share connection managers. I don't want to have 100 different connection managers.
  • subpackages, still this doesn't look very clean and I also wonder if this is what it is intended for. Also, the debugger goes crazy too opening the subpackages while running. Any other drawbacks I should know of?

I can't be the only person with this problem. Is there an other way to achieve this?

  • I suggest that if your package is that big then you need to work out how to logically break it into multiple packages. This doesn't help with deployment but does help with development. You can also break a package up by moving functionality into the database (i.e. calling stored procedures), and this is often faster. – Nick.McDermaid Jan 23 '17 at 1:35
  • Have you looked at BIDShelper and it's Smartdiff? – Tom V - try topanswers.xyz May 6 '17 at 12:25

I've been using subpackages successfully on multiple projects. The typical scope is one sub-package per target table. I also have a few utility packages eg Disable Indexes, Rebuild Indexes (on a table, passed as a parameter). A single "Master Control Package" is mostly Execute Package tasks.

With the Project Deployment method, devs need to be aware that prematurely checking in their changes to a single package can block the deploy (it wont deploy a project until all the packages validate cleanly).

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.