none
Package Configuration: Best Practices

    General discussion

  • I'd like some feedback on how people are managing package configurations in large environments.

    Currently we have written our own set up deployment tools in PowerShell that look for the .dtsConfig files in a specific path of the version control system. When the deployment system runs it copies the proper config files (whether it is dev, test, or prod) to the same path in the proper server environment (we have multiple dev, test, and production boxes).

    So far using this method has worked well for us, except when multiple solutions use the same configuration file. Our current solution to handle this is to use a SVN external to link to the shared file.

    I am curious to get some input on what other people are doing and what the best practices may be as well.
    Thursday, November 26, 2009 2:16 PM

All replies

  • hi can you explaie more about the problem please
    thanks

    do you have to use the same Config file for multiple pacakge?
    for just one pacakge how many config files do you have? and how many of them are shared bu other pacakges?
    can you give me an example of the data in each config file? e.g connection string , email to, email from , destination SQL server , destination DB name , etc...

    Sincerely SH -- Please kindly don’t forget to mark the post(s) that answered your question and/or vote for the post(s)
    Thursday, November 26, 2009 4:56 PM
  • Well there is a few different situations..

    Some packages only have their own configuration files..
    Some packages only used shared configuration files...
    Some packages use both shared and their own configuration files.

    Thursday, November 26, 2009 6:01 PM
  • Project Real framework uses admin.config table for all package configurations----its a very stable framework
    Thursday, November 26, 2009 6:11 PM
  • what i do is to make a same format for all my package configuration
    i have 2 cinfig files for each ETL
    1- Source config: e.g. connection string, etc..
    2- destination config: SQL server name DB name etc....
    3- email config: From Email, to email , smtp , etc...
    4- File and Folder Config: Wher to read source files , where to save backup , where to save txt error files and ertc...

    this way i have more control on each package and i can modify the file and simply overwrite the old file
    easy to move packages, easy to configure thing that the customer want to change the most , like backup folder, list of emails TO, etc...

    i have been using this technique for over 3.5 years never had a problem.

    i am just sharing experiances.
    Sincerely SH -- Please kindly don’t forget to mark the post(s) that answered your question and/or vote for the post(s)
    Thursday, November 26, 2009 6:23 PM