I'm having a hard time coming up with a development/release process for releases that include an SSIS package. Here is the scenario: I need to produce a report once a day and have it emailed to a couple of people. This is going to require: Some new stored procedures, functions, tables, etc An SSIS package, and a SQL Job that should run the package. A job which will run the SSIS package. I would like to be able to hand our deployment team something that they can easily deploy in different environments, i.e. dev, staging/integration, production. Now for our environments: Development: Single sql server with about 4 instances of each of our databases, one for each "environment". Sadly, there really isn't an equivalent for SSIS, so we only have one SSIS server in development. Staging: A single sql server with a copy of production and SSIS server installed. Production: A single machine which houses the SQL Server and SSIS. The problem is that the SSIS package exposes variables which are supposed to be set differently in each environment. I thought that I would do this via the job, but then the job has to be parameterized for each environment, which it may have to be anyway since in each environment the job runs the package off a different SSIS instance. I started looking at SSIS configuration. It's too bad that it doesn't allow you to specify your own SP for getting and setting a configuration. How do other people parameterize their releases of jobs and SSIS packages?

Store the configuration in a SQL server table and update values there for each set of parameters. Or store it in an XML file and ship it with each set of scripts/packages etc. Does this help? Or do you need more information?

SQL Server Table, imo, is the best option for managing multiple connections and changing those as you go through the development and deployment stages. This is a decent tutorial to set it up and will provide you with a good starting point.Please 'Mark as Answer' if found helpful - Chris@tier-1-support