Many years ago, Kirk Haselden wrote an article that essentially outlines what I'm about to describe:
In our packages we use an Indirect Configuration that points to a local XML configuration file on our workstations and servers. This configuration file contains the connection strings for our configuration, logging, staging and metrics databases.
This allows us to move packages around, or develop packages on more than one machine without having to reconfigure connection strings. The connection strings on production servers points to production databases and on developer workstations it either
points
locally or to a dev server. And so on.
Using package templates makes implementing this easy.
I'm working on porting some of our templates to SSIS 2012, and this doesn't seem possible anymore using SSIS projects and parameters.
For example, I created a project and package, set the project-level parameters to reflect the connection strings mentioned earlier and a couple of package-level parameters to some other connections. These connection strings referenced a local instance
of SQL Server (my laptop).
Now when I get the project from source control on my workstation, I have to change all the parameter values because I want to reference a local (my workstation) instance of SQL Server.
Is anyone else doing anything like this? How are you accomplishing it?
I'd really like to leverage SSIS projects and parameters, but it looks like we're going to have to stick with the Package Deployment Model unless we can figure this out.
How do you keep an SSIS 2012 package "in the dark?"