Deploying development packages to production

We have a system here where we develop SSIS packages on a development server. I am trying to figure out the cleanest way to promote these changes to a production server where stored procedures/tables that are used in the package are not deployed yet.

When I switch the connection in the package to the production server there are alot of objects in the package that are "invalidated" because they are trying to verify existence of tables/columns. One example is outputing the results of a query to a text file. The text file destination gets a red X on it because it cant grab the columns from the source query (because that stored procedure doesnt exist yet)

Is there a best practices or something on how to deploy packages to a production system? I have tried turning off "ValidateExternalMetaData" with no success.

Thanks!

I think you need to read up on configurations. Configurations allow you to change all sorts of properties/variables external to the ssis package itself.

-Try searching 'configurations' on this forum

-Read books on-line

-Or check many articles on Jamie Thompson's website

http://blogs.conchango.com/jamiethomson/

Hope this helps.

|||

CraigL77 wrote:

We have a system here where we develop SSIS packages on a development server. I am trying to figure out the cleanest way to promote these changes to a production server where stored procedures/tables that are used in the package are not deployed yet.

When I switch the connection in the package to the production server there are alot of objects in the package that are "invalidated" because they are trying to verify existence of tables/columns. One example is outputing the results of a query to a text file. The text file destination gets a red X on it because it cant grab the columns from the source query (because that stored procedure doesnt exist yet)

Is there a best practices or something on how to deploy packages to a production system? I have tried turning off "ValidateExternalMetaData" with no success.

Thanks!

If you use configurations (as Anthony suggested), you can set different connection strings for different environments. However, for the packages to run (and validate) in the production environment, the stored procs will have to be present.

If you change the connection strings in the package, you can ignore the validation errors and copy the packages to the server. They should run successfully as soon as the procs are created.