GIT上的SSIS解决方案？答案

【问题标题】：SSIS solution on GIT?GIT上的SSIS解决方案？
【发布时间】：2015-02-26 14:26:00
【问题描述】：

我找不到太多关于在 SSIS 解决方案中使用什么版本控制的资源。将 SSIS 解决方案放在 GIT 存储库上是否“正确”，或者对于此类项目还有其他（更好的）解决方案。我对 git 很熟悉，但我不确定它如何与 SSIS 一起工作，因为它主要是 UI 的东西，我不知道在 git 上是否会搞砸任何事情，是否有任何事情需要小心，等等。

【问题讨论】：

我们使用 TFS 并将 SSIS 包也视为二进制文件。合并 SSIS 包或编辑 XML 时不加注意是破坏 SSIS 包的好方法。

标签： git version-control ssis solution

【解决方案1】：

相反，SSIS 的接口通常是通过 UI 实现的，但其核心是大量的 XML。

所以是的，您可以并且应该对您的 SSIS 解决方案进行版本控制，就像您应该对您开发的任何东西进行版本控制一样。合并 XML 充其量是冒险的，无论是“直接” XML 还是我们通过 SSIS 获得的：描述工作流的 XML 和，嵌入在 XML 中的是更多描述 GUI 元素布局的 XML。在合并 SSIS 包时，布局和工作的混合会导致很多冲突。有像BIDS Helper 这样的工具试图提供“智能差异”。我发现识别“此数据流已更改”对我很有帮助，但除此之外，我将 SSIS 包视为源代码控制中的二进制对象。

无论您使用 git、mercurial、svn、csv、rcs、perforce、tfs、sourcesafe 还是任何其他工具，都 100% 与被版本控制的内容类型无关。

【讨论】：

GitHub被SSIS收购后有什么进展吗？希望这些工具之间能够更好地集成。
@ColinMac 不。不幸的是，在这一点上，我认为很明显 MS 对在 SSIS 上花费更多的工程资金不感兴趣。它在一段时间内不会作为产品消失，因为他们已经在 Azure 数据工厂 (ADF) 中添加了支持，但那是 MS 希望通过数据移动获利的地方。
我觉得这个答案模棱两可。你是说 SSIS 包*不是* 源代码（纯文本）而是压缩的二进制文件因此将它们放入 SCM 是浪费时间/精力 或者你的意思是 虽然为 SSIS 做 SCM 很困难, 只需使用 SCM ?
@RajeshSwarnkar 是的，版本控制你的包。少做点什么都是不专业的。 SSIS 包是 XML，因此它是一个文本文件。但是，由于它是 XML，生成包版本之间的差异通常没有帮助，因为等效结构会在差异报告中显示更改。例如<root><a/><b/></root> 与<root><b/><a/></root> 不一样 SSIS 可以选择两种方式编写“相同”的包。从逻辑上讲，它们代表相同的信息，但在物理上，它们是不同的。版本控制中的 SSIS：可以，但差异报告可能没用。

【解决方案2】：

我不喜欢将 SSIS（和 SSRS）文件放在 git 中，因为它们不能合并。

在 TFS 中，我可以通过使用锁来防止其他开发人员在同一个包上工作。在 git（带 git 的 VSTS）中，我无法阻止其他人使用锁编辑同一个包。

【讨论】：