Post reply

SSIS Source Control

  • February 25, 2020 at 1:51 pm

    #3728585

    Hello, our environment consists of one Azure VM, a "utility" server with SQL Server 2017 DB engine, SSIS and SSRS installed (we are small shop).  We are in the process of migration about 50 SSIS packages from a SQL Sever 2012 environment and would like implement source control, as we have three people that need to create and maintain SSIS packages.

    We have never implemented source control before so we are struggling a bit with getting it set up.  We want just the absolute bare bones, check in, check out functionality so we aren't overwriting each other's work.  All of our packages exist under one SSDT Solution/project who's source code resides on the utility server.

    It seems like our two options are git and  Azure Devops Services (formerly Team Foundation Server).  From what I've read, git seems to the wrong fit for what we want to do, so we have signed up for a "free" (< 5 users) Azure Devops Services account and are trying to get that configured but as mentioned above are struggling to get it set up for our needs (very basic - source control only).

    Any advice or points in the right direction documentation/blog wise are much appreciated, as we haven't been finding the right ones.

    Thanks,

    DM

  • February 25, 2020 at 2:53 pm

    #3728603

    We use Git on Azure DevOps – and that is what I would recommend. In my opinion, it's way faster and more lightweight to use than TFS.

    When you say that Git is the 'wrong fit' for you, can you be a bit more specific?

    Also, as you are all going to be working on a single project, you are in for a hard time, regardless of which VCS you use. That's because SSIS projects and packages don't merge very well, if at all.

    That's for a couple of overall reasons:

    1. You have a shared project file, which is updated whenever packages are added or deleted, or when project-scoped parameters or connections are added, amended or deleted. Merging these can be tricky, but it's possible, if you know what you're doing.
    2. If two developers modify the same packages, merging the changes into a single package containing both sets of changes is unlikely to work – the structure of SSIS packages is too complex, despite them being XML. You need to ensure that the devs work on separate packages to avoid this (which should be easy enough, as there are not many of you).

    If you are able to split the packages into multiple projects, by grouping them somehow, it will make things easier for you.

    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

  • February 25, 2020 at 3:21 pm

    #3728616

    We personally use Subversion at the office. It's fine for other Visual Studio Projects, and VSCode, however, it isn't great with SSRS and it's literally awful with SSIS. Unfortunately I'm stuck with suffering with what we have, so this is just my input of don't use Subversion with SSIS.

    Thom~

    Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
    Larnu.uk

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

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