Best Practices for SSIS Connection Managers in Source Control: Visual Studio

  • Hi All, what are the best practices for storing connection managers in Source Control?    For example, if you have a SSIS solution with a Dev Server Connection Manager, and you merge that up to the PROD branch in Source Control in Visual Studio, do you keep the connection manager as DEV on the PROD branch, or do you change the connection manager to the PROD server on the PROD branch.

    I've heard a discussion where the idea was to store the DEV connection manager on the PROD branch and set the PROD connection manager up on the Job parameters.  The idea was to not accidentally deploy a PROD connection manager anywhere in case someone deployed a PROD package on a DEV server to test it, etc.  (I know this is not a great idea.)

    It does seem safer for the PROD system to keep them all Conn mgrs set as DEV in source control and ensure the connection manager is set per job, but I'm open to hearing other ideas.  Thanks for the help.

    • This topic was modified 2 years, 3 months ago by  mjninc.
  • Yes, conn managers should be checked in with dev / local connections and that is how they should remain, as far as source control is concerned.

    After deploying packages to QA / Production, use SSISDB environment variables to override the checked-in values with the environment-specific values. That also goes for any other environment-specific parameters (eg, file paths).

    The absence of evidence is not evidence of absence
    - Martin Rees
    The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
    - Phil Parkin

  • Thank you Phil!

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply