Keeping SSIS Packages Under Source Control

Question

I store all SSIS packages in the Subversion repository, their configuration files. The configuration file is almost always stored in the same folder as the package.

Problem: SSIS always seems to save the path to the configuration file (the one that is saved in the package itself) as an absolute path.

When someone else checks the package folder in a place other than where I was on my development computer, the configuration file was not found (since my absolute path is stored and it is not on the other developer's computer). Therefore, another developer should delete this configuration and add it again, from where it is located on the local hard drive. Then the saved package is saved, which will commit the new version. When I get this version from SVN, it will no longer match the local path on my PC.

In a related note: another developer may want to change the values ​​in the configuration file. If I later get the latest version of everything that from the SVN package will no longer work on my PC.

How did you get around this inconvenience?

Answer 1

Another solution is to save your configuration in a database with an environment variable as the first configuration to tell which database it is in, what we are doing. We have scripts to populate ssisconfig for each server in our source control, but the package uses the actual table data for the database in the environment variable that we use.

Answer 2

Anyone who has heard my Saturday SQL presentations knows that I don't really care about XML, and that’s one of the reasons. The trick using XML configuration in different places is to use an environment variable (indirect configuration) for direct access to SSIS, where it can look for this resource. The big, big drawback of this approach is that you usually need to create an environment variable for each set of configuration files or have a massive, tracking .dtsconfig file that becomes painful for version control.

The option that I prefer if XML configuration is required is that the "volatility" is removed. Developers and administrators get together, and everyone agrees: "There will be a folder in which SSIS is run to store the configuration files, and this is the location of X," and then this is just a solution to X. In the previous work, we used D: \ ssisdata \ configs

Table approach

@HLGEM tables for configurations is my favorite approach to configuring SSIS (until you get to 2012 and their project deployment model, where configuration is a completely different animal)

Answer 3

I add a folder called "config" to my projects folder, add it to the original control and save the configuration file in this folder. You can also add it to your SSIS project if you wish.

I think this is a good solution, because everyone can have this folder and upload the configuration file.

When the package is deployed, it will read the configuration file from which you report in the deployment manifest so that this solution does not affect your development.