If there is such a thing as divine retribution, then I’m pretty sure that most of the people on Microsoft’s SSIS product team will be spending eons merging SSIS packages.

I took the following screenshot from an issue I reviewed at my old job. The developer who resolved the issue only made two property changes and realigned the boxes in the visual designer (can you say OCD), so I expected to see a small diff but instead saw this unholy mess.

For those of you who are not familiar with BeyondCompare, all those red bars on the left represent changes to the file (100’s of lines).

Since only two meaningful changes occurred in the revision, that means that the vast majority of it is noise related to tracking the positions of all the elements rendered by the visual designer.

Is the visual tooling here so essential that it is really worth losing the ability to track and comprehend how the code has changed over time?

What about the ability to collaborate or work in parallel on tasks?

At my last job it was extremely common for devs to work on different features at the same time that touched the same code files. Unless the exact same lines of code were changed, the devs were able to merge these files with little or no effort.

However, when it came to SSIS packages we were forced to ditch the last 10 years of software engineering best practices and instead expend vast amounts of effort in planning and endure ridiculous amounts of inefficiency just to ensure that no devs even thought about touching the same SSIS package at the same time.

If the dreaded merge window did ever appear during the check-in dance on an SSIS package, devs habitually ditched the merge tool and instead relied on the extremely tedious and error-prone approach of manually reapplying all the changes through the visual designer.

I realize that there are quite a few developers who work in small shops and don’t have to deal with scenarios involving extensive collaboration and parallel development, but what about the case of a hotfix that happens in the middle of a multi-week project?

With a normal code file you would be to follow a simple mainline-release pattern, make a change to the release branch, then merge back into the mainline branch.

However, with SSIS the only alternatives are to either lose work, try to do some wonky work-around with a data load, or else just throw throw yourself at the mercy of your boss and try to convince them to delay the hotfix until the larger project is done.

Did nobody on the SSIS team consider these issues when designing the product or was SSIS really just meant to be a basic end-user tool like Access?

Perhaps this is one of those situations like with VSS where everyone who actually works at Microsoft uses some other ETL tool that allows them to follow basic modern software development practices.

Then again, maybe the development community as a whole has just become so blinded by the desire and expectation for visual tooling that it trumps all other considerations.

Whatever the reason, there is no way I would ever voluntarily use SSIS again.

Does anyone know of any more source control friendly alternatives?

Popularity: 4% [?]