Jamie’s post touches on one potential problem of having SSIS packages that are too big: errors with Source Safe while checking in. SSIS Packages are saved as xml documents, SourceSafe is going to put in a lot of effort to save the delta changes of the xml between saves. While I haven’t encountered this problem in my environment, Jamie does make a suggestion which is very valuable: “Keep your packages as small as can be. A modular approach to development can be of real benefit”.

I’d definitely agree with Jamie on this approach, especially when using SourceSafe in a team development environment. Because SSIS Packages are XML, you cannot assume that SourceSafe is going to safely merge changes from shared checkouts. In short: you cannot have multiple developers working on the same package at once.

When designing/developing a package, ensure only a single task / dataflow is put into a Data Flow task. Group Control Flow tasks with a Sequence Container when you can. When you find your package is becoming too big, or you need to have more than one developer working on it at once, you can easily move the group to a new package, and use an Execute Package Task in the parent to keep the control flow.

In addition to thereby enabling your project to have more developers working at once, you are also gaining finer control of packages and tracking of changes. In an article on Event Handler Issues, Daniel Read takes issue that Event Handlers fire too often. If his packages had been more modular, with a parent package calling multiple (sub)packages, enabling events only in the parent package would be suffice. Event Handlers in the child packages would not be necessary.

So some quick tips on using SSIS with SourceSafe:

  1. Use exclusive checkouts (not shared checkouts) for SSIS Package files.
  2. Group Control Flow tasks with Sequence Containers in case you want to break up a package later.
  3. Use the Execute Package Task to call other packages from a parent package.
  4. Log the Package Version with your custom Event Handlers so you know what version ran when.

On Jamie’s other note to backup your SourceSafe: that�s a definite. I would backup any resource that is part of your work; source code is especially precious. SourceSafe can be used for tracking changes and little incremental backups of daily work. But backing up SourceSafe helps you recover from detrimental changes to SourceSafe (like permanently deleting a SourceSafe project) or from corruption of SourceSafe itself.

Tags: