In my opinion, a big disadvantage is also the fact, that you cannot create folders in the deployed project. So you are not able to group your packages.

Thanks. The project deployment model does suffer from some annoying quirks from a “developer collaboration” perspective as well, for example a project has to be deployed in full everytime, and you cannot deploy individual SSIS packages, making deployment in a team environment a bit inconvenient to manage, but the benefits (for my projects atleast) outweigh those issues.

I have written an article that helps truncate the SSIS catalog DB, this is a brute force solution that helps maintain your SSIS catalog, but I am yet to complete a list of optimization tips (been busy playing with Hadoop and HDInsight recently). Do you suffer from any particular issues that you would like me to tackle or give attention to in the article?

Wil you be updating this post with your optimization tips anytime soon?

Thanks!

I’ve actually recently started to notice a few more issues with this new project deployment model, particularly when handling a busy SSIS environment. Mostly these issues are related to bad default configurations on the SSISDB or environment (isolation modes, read/write conflicts and time-outs), mostly can be avoided by configuring the DB and environment manually (and not just leaving it on the default out-of-the-box configuration), but more serious ones like stray SSIS packages executing for days for no reason (and holding off log file checkpoints), and random errors when deploying to the catalog server, are much harder to debug.

I’ll probably be releasing a few optimization tips to help avoid issues when running a high volume of SSIS packages, so watch this space if you are interested!