SSIS中的源代码控制和dtsx文件的并发工作

Question

我正在从头开始构建一个新的SSIS项目。我想和几个队友一起工作。我希望得到一个关于如何让一些人拥有一些源代码控制的建议，这样我们很少有人可以在同一个SSIS项目上同时工作（相同的dtsx文件，构建新的软件包。） 版： SQL Server集成服务v11 Microsoft Visual Studio 2010

Answer 1

根据我的经验，任何源控制系统和SSIS项目都有两个机会摆脱困境：向项目中添加新项目以及对现有软件包进行并发更改。

添加新项目

SSIS项目具有.dtproj扩展名。在那里，它是“只是”XML定义所有属于项目的东西。至少在2005/2008和2012+上的包部署模型。 2012 + 项目部署模型提供了有关项目中包状态的更多信息。

当您添加新包（或项目级连接管理器或.biml文件）时，.dtproj文件的内部结构将发生变化。差异工具通常不能很好地处理XML。或者真的。因此，为了防止合并项目定义的需要，您需要找到适合您团队的策略。

我见过两种方法效果很好。首先是预先定义您认为需要的所有包。 DimFoo，DimDate，DimFoo，DimBar，FactBlee。检查项目和相关的空包，每个人都在那里工作。当包的初始剪切完成后，您将确保每个人都已同步，然后向项目添加更多空包。这里的想法是，有一个人，通常是负责人，负责改变“主”项目定义，每个人都从他们的变化中消费。

另一种方法需要团队成员之间的沟通。如果您发现需要添加一个包，请与您的伙伴沟通“我需要添加一个新包 - 有没有人修改过该项目？”答案应该是否定。一旦您通知项目定义的更改即将到来，请立即提交并立即提交。这里的想法是人们以极高的频率提交和同步/检查任何术语。如果您作为开发人员不保持本地存储库的最新状态，那么您将会陷入困境。

并发编辑

别。真的，就是这个。 SSIS包的并发更改的一般问题是，除了上面的XML diff问题之外，SSIS 还包括布局数据和任务，因此我可以反转布局并使事物从下到上流动或从右到左，SSIS包装没有重大变化，但Siyual指出“合并SSIS的变化是噩梦般的燃料”

如果您发现您的软件包太大而开发人员需要进行并发编辑，我建议您在那里做太多。将您的包分解为更小，更紧密集中的工作单元，然后通过父包控制它们的执行。除了避免并发编辑问题之外，这将为您的开发和调试过程提供更好的粒度级别。

Answer 2

dtsx文件基本上只是一个xml文件。将它与一群试图写同一本书的人比较。我建议的解决方案是使用Team Foundation Server作为源代码控制。这样每个人都可以签入和签出并合并包。如果你真的没有这个选项，试着在逻辑部分拆分你的ETL过程，最后创建一个主包，按正确的顺序调用每个子包。

一个例子：假设您需要从内部服务器导入来自一个来源，分支机构和其他公司信息的库存数据，以及从不同外部来源导入销售额。收集完所有信息后，您需要连接这些信息并运行一些分析。

首先设计所需的目标数据库实体和关系。您的一个成员创建一个包，该包执行到登台表的所有导入。另一个人可能会处理外部源并并行化/优化负载。您将构建一个包合并暂存和生产表的包，可能是历史化等等。 最后，你有一个主包，可以调用每个提到的包，也许还有一些额外的日志记录等。

Answer 3

在两个开发人员的操作中，我们遵循以下粗略计划：

• 每个开发者都有自己的分支，与主分支分开
• 每周一次，开发人员将所有更改推送到远程
• 我们中的一个人拉动所有更改，并将所有分支合并到master中，从而在解决过程中手动解决.dtproj冲突
• 在所有dev分支中合并管理员-现在所有分支都同意
• 在VS中测试
• 将所有分支推送到远程站点，其他开发人员现在可以拉出并继续工作

这不是一个完美的解决方案，但可以帮助隔离我们必须经历的合并难题。

Answer 4

我们有大型 ssis 解决方案，在一个解决方案中包含 20 多个包，使用 TFS Git。一个项目需要向现有解决方案添加一堆新包。我们认为我们很聪明，并且知道只分配一个人来处理每个新包，两个人处理同一个包就是自杀。不够好。当两个人尝试同时添加一个不同的命名的新包时，每个人都将 dtproj 显示为一个已更改/需要签入的文件，突然我发现自己在查看 dtproj 的 xml 并试图找出哪些行保留（微软不应该要求最终用户手动编辑他们的内部文件，只有他们自己写和理解）。 Billinkc在这里的解决方案非常好，问题也很真实。您可能认为 Microsoft 是伟大的 Wise One，并且您的团队始终可以向现有解决方案添加新程序包而不会发生冲突，但您错了。将 dtproj 放入 .gitignore 也不起作用。如果这样做，您将不会看到其他人的新包（实际上 .dtsx 文件会在 git 中出现，但您不会在解决方案资源管理器中看到该包，因为 dtproj 是解决方案资源管理器的馈送）。这是当前的问题 (2021)，我们正在使用带有 SSDT 的 Visual Studio 2017 Enterprise。

为了向人们解释这个问题，git 显然可以处理目录中一组独立的单个文件（例如 .bat 文件），并且可以轻松添加、更改和删除这些文件。当您有一个文件命名、描述和计算目录中的所有文件（dtproj 所做的）时，问题就出现了。当你有一个像 dtproj 这样的文件时，你就会在 dtproj 本身上产生冲突，当两个人同时尝试添加一个新包时。您的 dtproj 文件中有一行显示您添加的包，而我的 dtproj 文件显示了我添加的包，而 tfs/git 将其视为冲突。

如果您必须添加很多新包，有些人会建议如何处理这个问题，我的想法有点不同。对于必须添加新包的人，不要在出现此问题的主要解决方案中工作，而在其他地方工作。可能最好在安装 Visual Studio 时在 TFS/Git 之外获得的“项目”目录中工作。显然遵循目标解决方案的所有标准、变量命名和包配置约定。然后，当新包准备就绪时，将 .dtsx 文件提供给您的 Solution Gatekeeper 以供他们签入。只有 Gatekeeper 可以使用 Add From Existing 签入新包，避免冲突。签入包后，开发人员可以在主解决方案中处理它们。