12

I can't find much resources about what version control to use with SSIS solution. Is it "proper" thing to do to put SSIS solution on GIT repository or there are other (better) solutions for this type of projects. I am familiar with git but I am not sure how would it work with SSIS since it's mostly UI thing I don't know if putting on git can mess up anything, are there any things to be careful with, etc.

JoelC
  • 3,664
  • 9
  • 33
  • 38
ilija veselica
  • 9,414
  • 39
  • 93
  • 147
  • 3
    We use TFS and treat the SSIS packages as binaries as well. Merging SSIS packages or editing the XML without the appropriate amount of caution is an excellent way to break your SSIS packages. – Eric Hauenstein Feb 26 '15 at 14:54

2 Answers2

19

Au contraire, the interface to SSIS is generally through a UI but at the heart it's an ungodly amount of XML.

So yes, you can and should version control your SSIS solutions, as you should version control anything you develop. Merging XML is dicey at best, whether it's "straight" XML or what we get with SSIS: XML that describes the workflow and, embedded in that XML is more XML that describes the layout of GUI elements. That mix of layout and work leads to a lot of conflicts when merging SSIS packages. There are tools like BIDS Helper that attempt to provide a "smart diff". I find that it's helpful for me to identify "this data flow changed" but otherwise, I treat SSIS packages as binary objects in source control.

Whether you use git, mercurial, svn, csv, rcs, perforce, tfs, sourcesafe or any other tool is 100% immaterial to the type of content being versioned.

billinkc
  • 59,250
  • 9
  • 102
  • 159
  • Have there been any developments since GitHub was acquired by SSIS? Hopefully better integration between these tools. – ColinMac May 21 '20 at 18:44
  • 2
    @ColinMac Nope. Unfortunately at this point, I think it's fairly clear MS is not interested in spending any more engineering dollars on SSIS. It won't go away as a product for some time as they've added support into Azure Data Factory (ADF) but that's where MS is looking to monetize data movement. – billinkc May 21 '20 at 21:17
  • I find this answer ambiguous. Do you say that _SSIS packages are *not* source code (plain text) but compressed binary hence putting them into SCM is waste of time/effort_ or you mean _although doing SCM for SSIS is difficult, just use SCM_ ? – Rajesh Swarnkar Jan 11 '22 at 06:11
  • @RajeshSwarnkar Yes, version control your package. To do anything less would be unprofessional. An SSIS package is XML, therefore it's a text file. However, since it's XML, generating a difference between package versions is generally not helpful as equivalent structures will show changes on a difference report. e.g. `` is not the same as `` SSIS can choose to write the "same" package in both ways. Logically they represent the same information but physically, they are different. SSIS in version control: Yes do it, but a diff report is likely useless. – billinkc Jan 11 '22 at 19:12
  • @billinkc. I gather treating packages as binaries amounts to: 1. Don't work on packages independently (since you can forget about being able to merge branches), and 2. To bring a branched VSS solution back into a master branch, copy the dev solution somewhere, checkout master and just replace the master VSS solution wholesale. – Jai Jeffryes Mar 08 '23 at 21:01
  • @JaiJeffryes I think your summation is accurate. Treat it as a binary because a text merge will result in a broken package. – billinkc Mar 09 '23 at 01:31
0

I do not like putting SSIS (and SSRS) files in git since they are not merge-able.

In TFS I can prevent other developers from working on the same package by using locks. In git (VSTS with git) I was not able to prevent others from editing the same package using locks.

DejanS
  • 96
  • 9