SSIS 中的源代码控制和 dtsx 文件的并发工作
Source control in SSIS and Concurrent work on dtsx file
我正在从头开始构建一个新的 SSIS 项目。我想和我的几个队友一起工作。我希望得到关于我们如何拥有一些源代码控制的建议，这样我们中的少数人就可以同时处理同一个 SSIS 项目（同一个 dtsx 文件，构建新包。）
版本：
SQL 服务器集成服务 v11
微软 Visual Studio 2010
根据我的经验，任何源代码控制系统和 SSIS 项目都有两个机会摆脱困境：向项目添加新项目和同时更改现有包。
添加新项目
SSIS 项目的扩展名为 .dtproj。在里面，"just" XML 定义了所有属于该项目的内容。至少在 2005/2008 和 2012+ 包部署模型上。 2012+ project 部署模型包含更多关于项目中包状态的信息。
当您添加新包（或项目级连接管理器或 .biml 文件）时，.dtproj 文件的内部结构将发生变化。差异工具通常不能很好地处理合并 XML。或者根本不是真的。因此，为了避免合并项目定义的需要，您需要找到适合您团队的策略。
我见过两种方法效果很好。首先是预先定义您认为需要的所有包。 DimFoo、DimDate、DimFoo、DimBar、FactBlee。检查该项目和相关的空包，然后每个人都在处理那里的内容。当包的初始切割完成后，您将确保每个人都同步，然后将更多空包添加到项目中。这里的想法是，只有一个人（通常是领导）负责更改 "master" 项目定义，每个人都从他们的更改中消费。
另一种方法需要团队成员之间的沟通。如果您发现需要添加包，请与您的伙伴沟通 "I need to add a new package - has anyone modified the project?" 答案应该是否定的。一旦您通知项目定义即将发生更改，请进行更改并立即提交。这里的想法是人们以任何术语频繁地提交和 sync/check。如果您作为开发人员不使您的本地存储库保持最新状态，那么您将度过一段糟糕的时光。
并发编辑
不要。真的，就是这样。并发更改 SSIS 包的一般问题是，除了上面的 XML 差异问题之外，SSIS 还 包括任务旁边的布局数据，因此我可以反转布局并制作事情从下到上或从右到左流动，没有 material 更改 SSIS 包，但正如 Siyual 所说 "Merging changes in SSIS is nightmare fuel"
如果您发现您的包太大并且开发人员需要进行并发编辑，我建议您在那里做的太多了。将您的包分解为更小、更集中的工作单元，然后通过父包控制它们的执行。除了避免并发编辑问题之外，这还可以为您的开发和调试过程提供更好的粒度级别。
dtsx 文件基本上只是一个 xml 文件。将它与一群试图写同一本书的人进行比较。我建议的解决方案是使用 Team Foundation Server 作为源代码管理。这样每个人都可以签入和签出并合并包。如果您确实没有该选项，请尝试将 ETL 过程拆分为逻辑部分，最后创建一个主包，以正确的顺序调用每个子包。
举个例子：假设您需要从一个来源导入库存数据，从内部服务器导入分支机构和其他公司信息，并从不同的外部来源导入销售额。收集完所有信息后，您想将这些信息联系起来并 运行 进行一些分析。
您首先设计您需要的目标数据库实体和关系。您的一位成员创建了一个包，该包执行所有导入到登台表的操作。另一个人可能会处理外部资源并并行化/优化加载。您将构建一个包，合并您的暂存表和生产表，可能进行历史化等等。
最后你有一个主包，它调用每个提到的包，可能还有一些额外的日志记录等。
在我们的多开发者操作中，我们遵循这个粗略的计划：
- 每个 dev 都有自己的分支，独立于 master 分支
- 开发人员每周一次将他们的所有更改推送到远程
- 我们中的一个人拉取所有更改，并将所有分支合并到 master 中，边走边手动解决 .dtproj 冲突
- 在所有开发分支中合并 master - 现在所有分支都同意
- 在 VS 中测试
- 将所有分支推送到远程，其他开发人员现在可以拉取并继续工作
这不是一个完美的解决方案，但它有助于隔离我们必须经历的合并痛苦。
我们有大型 ssis 解决方案，在一个解决方案中包含 20 多个包，带有 TFS Git。一个项目需要向现有解决方案添加一堆新包。我们认为我们很聪明，知道只分配一个人处理每个新包，两个人处理同一个包会自杀。不够好。当 2 个人尝试同时添加一个不同的命名新包时，每个人都将 dtproj 显示为一个文件，其中 changed/needed 需要签入，突然我发现自己正在查看 dtproj 的 xml 和试图弄清楚要保留哪些行（Microsoft 永远不应该要求最终用户手动编辑他们的内部文件，这些文件只有他们自己编写和理解）。 bilinkc这里的解决方案很好，问题也很现实。您可能认为 Microsoft 是伟大的智者，并且您的团队总是可以在不发生冲突的情况下向现有解决方案添加新包，但您错了。将 dtproj 放在 .gitignore 中也不起作用。如果这样做，您将看不到其他人的新包（实际上 .dtsx 文件将在 git 中出现，但您不会在解决方案资源管理器中看到该包，因为 dtproj 是解决方案资源管理器的源）。这是一个当前问题 (2021)，我们正在使用 Visual Studio 2017 Enterprise with SSDT。
为了向人们解释这个问题，git 显然可以处理目录中的一组独立的、单独的文件（比如 .bat 文件），并且可以轻松地添加、更改和删除这些文件。当您有一个文件正在命名、描述和计算目录中的所有文件（dtproj 所做的）时，问题就出现了。当你有一个像 dtproj 这样的文件时，当 2 个人试图同时添加一个新包时，你就会在 dtproj 本身上产生冲突。您的 dtproj 文件有一行显示您添加的包，而我的 dtproj 文件显示我添加的包，tfs/git 将其视为冲突。
如果你必须添加很多新包，有些人建议如何处理这个问题，我的想法有点不同。对于必须添加新包的人，不要在出现此问题的主要解决方案中工作，在其他地方工作。可能最好在安装 Visual Studio 时获得的“项目”目录中工作，在 TFS/Git 之外。显然要遵循目标解决方案的所有标准、变量命名和包配置约定。然后，当新包准备就绪时，将 .dtsx 文件提供给您的 Solution Gatekeeper 以便他们签入。只有 Gatekeeper 可以使用从现有添加签入新包，避免冲突。包签入后，开发人员可以在主解决方案中处理它们。
我正在从头开始构建一个新的 SSIS 项目。我想和我的几个队友一起工作。我希望得到关于我们如何拥有一些源代码控制的建议，这样我们中的少数人就可以同时处理同一个 SSIS 项目（同一个 dtsx 文件，构建新包。） 版本： SQL 服务器集成服务 v11 微软 Visual Studio 2010
根据我的经验，任何源代码控制系统和 SSIS 项目都有两个机会摆脱困境：向项目添加新项目和同时更改现有包。
添加新项目
SSIS 项目的扩展名为 .dtproj。在里面，"just" XML 定义了所有属于该项目的内容。至少在 2005/2008 和 2012+ 包部署模型上。 2012+ project 部署模型包含更多关于项目中包状态的信息。
当您添加新包（或项目级连接管理器或 .biml 文件）时，.dtproj 文件的内部结构将发生变化。差异工具通常不能很好地处理合并 XML。或者根本不是真的。因此，为了避免合并项目定义的需要，您需要找到适合您团队的策略。
我见过两种方法效果很好。首先是预先定义您认为需要的所有包。 DimFoo、DimDate、DimFoo、DimBar、FactBlee。检查该项目和相关的空包，然后每个人都在处理那里的内容。当包的初始切割完成后，您将确保每个人都同步，然后将更多空包添加到项目中。这里的想法是，只有一个人（通常是领导）负责更改 "master" 项目定义，每个人都从他们的更改中消费。
另一种方法需要团队成员之间的沟通。如果您发现需要添加包，请与您的伙伴沟通 "I need to add a new package - has anyone modified the project?" 答案应该是否定的。一旦您通知项目定义即将发生更改，请进行更改并立即提交。这里的想法是人们以任何术语频繁地提交和 sync/check。如果您作为开发人员不使您的本地存储库保持最新状态，那么您将度过一段糟糕的时光。
并发编辑
不要。真的，就是这样。并发更改 SSIS 包的一般问题是，除了上面的 XML 差异问题之外，SSIS 还 包括任务旁边的布局数据，因此我可以反转布局并制作事情从下到上或从右到左流动，没有 material 更改 SSIS 包，但正如 Siyual 所说 "Merging changes in SSIS is nightmare fuel"
如果您发现您的包太大并且开发人员需要进行并发编辑，我建议您在那里做的太多了。将您的包分解为更小、更集中的工作单元，然后通过父包控制它们的执行。除了避免并发编辑问题之外，这还可以为您的开发和调试过程提供更好的粒度级别。
dtsx 文件基本上只是一个 xml 文件。将它与一群试图写同一本书的人进行比较。我建议的解决方案是使用 Team Foundation Server 作为源代码管理。这样每个人都可以签入和签出并合并包。如果您确实没有该选项，请尝试将 ETL 过程拆分为逻辑部分，最后创建一个主包，以正确的顺序调用每个子包。
举个例子：假设您需要从一个来源导入库存数据，从内部服务器导入分支机构和其他公司信息，并从不同的外部来源导入销售额。收集完所有信息后，您想将这些信息联系起来并 运行 进行一些分析。
您首先设计您需要的目标数据库实体和关系。您的一位成员创建了一个包，该包执行所有导入到登台表的操作。另一个人可能会处理外部资源并并行化/优化加载。您将构建一个包，合并您的暂存表和生产表，可能进行历史化等等。 最后你有一个主包，它调用每个提到的包，可能还有一些额外的日志记录等。
在我们的多开发者操作中，我们遵循这个粗略的计划：
- 每个 dev 都有自己的分支，独立于 master 分支
- 开发人员每周一次将他们的所有更改推送到远程
- 我们中的一个人拉取所有更改，并将所有分支合并到 master 中，边走边手动解决 .dtproj 冲突
- 在所有开发分支中合并 master - 现在所有分支都同意
- 在 VS 中测试
- 将所有分支推送到远程，其他开发人员现在可以拉取并继续工作
这不是一个完美的解决方案，但它有助于隔离我们必须经历的合并痛苦。
我们有大型 ssis 解决方案，在一个解决方案中包含 20 多个包，带有 TFS Git。一个项目需要向现有解决方案添加一堆新包。我们认为我们很聪明，知道只分配一个人处理每个新包，两个人处理同一个包会自杀。不够好。当 2 个人尝试同时添加一个不同的命名新包时，每个人都将 dtproj 显示为一个文件，其中 changed/needed 需要签入，突然我发现自己正在查看 dtproj 的 xml 和试图弄清楚要保留哪些行（Microsoft 永远不应该要求最终用户手动编辑他们的内部文件，这些文件只有他们自己编写和理解）。 bilinkc这里的解决方案很好，问题也很现实。您可能认为 Microsoft 是伟大的智者，并且您的团队总是可以在不发生冲突的情况下向现有解决方案添加新包，但您错了。将 dtproj 放在 .gitignore 中也不起作用。如果这样做，您将看不到其他人的新包（实际上 .dtsx 文件将在 git 中出现，但您不会在解决方案资源管理器中看到该包，因为 dtproj 是解决方案资源管理器的源）。这是一个当前问题 (2021)，我们正在使用 Visual Studio 2017 Enterprise with SSDT。
为了向人们解释这个问题，git 显然可以处理目录中的一组独立的、单独的文件（比如 .bat 文件），并且可以轻松地添加、更改和删除这些文件。当您有一个文件正在命名、描述和计算目录中的所有文件（dtproj 所做的）时，问题就出现了。当你有一个像 dtproj 这样的文件时，当 2 个人试图同时添加一个新包时，你就会在 dtproj 本身上产生冲突。您的 dtproj 文件有一行显示您添加的包，而我的 dtproj 文件显示我添加的包，tfs/git 将其视为冲突。
如果你必须添加很多新包，有些人建议如何处理这个问题，我的想法有点不同。对于必须添加新包的人，不要在出现此问题的主要解决方案中工作，在其他地方工作。可能最好在安装 Visual Studio 时获得的“项目”目录中工作，在 TFS/Git 之外。显然要遵循目标解决方案的所有标准、变量命名和包配置约定。然后，当新包准备就绪时，将 .dtsx 文件提供给您的 Solution Gatekeeper 以便他们签入。只有 Gatekeeper 可以使用从现有添加签入新包，避免冲突。包签入后，开发人员可以在主解决方案中处理它们。