Split SSIS project in to multiple files to avoid merge hell 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'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).