我们即将使用 SSIS 将数据从一个系统转换到另一个系统。我们是四个人，他们将持续为此工作两年，因此我们需要某种版本控制系统。我们不能使用团队基础。我们目前正在配置一个 SVN 服务器，但是深入研究它我发现了一些很大的风险。
似乎解决方案存储在一个巨大的 XML 文件中。这在作为 SSIS 的组合代码/拖放环境中一定是一个大问题，因为 SVN 无法正确合并更改，并且每当我们在提交时遇到错误时，我们都必须查看那个巨大的 XML 文件和手动更正错误。
解决此问题的一种方法是在 SSIS 中创建许多解决方案项目。然而，这并不是我们真正想要的设置，因为我们正在创建一个大型怪物，它将有 2 天的时间来执行，我们希望在它执行时跟踪它的进度。如果我们必须创建多个解决方案，有没有办法将它们的执行联系起来，并且仍然可以直观地了解正在发生的事情以及执行的效果如何？
有没有人遇到过类似的问题和/或您对如何解决这些问题有任何建议？
【问题讨论】：
标签： version-control ssis
你说的是多少包？如果是数百个包，那么您要避免的具体问题是什么？根据您的帖子，您可能会尝试避免以下几点：
在 BIDS 中启动时解决方案和项目加载时间缓慢。我想这可能会时不时地让人恼火。但是，如果您整天保持 BIDS 开放，这似乎是一天一次的费用。
当您从版本控制系统获取最新的解决方案定义时，解决方案和项目加载时间会变慢。同样，我想这可能会不时让人恼火，但是您需要多久刷新一次整个解决方案？如果您将解决方案分解为单独的项目，那么您只需要刷新一个项目。如果您想访问解决方案中的新项目，您只需刷新整个解决方案。
“一个巨大的 XML 文件”是什么意思？解决方案文件是一个跟踪项目的 XML 文件。每个项目文件都是一个跟踪其 SSIS 包的 XML 文件。因此，如果您有 1,000 个 SSIS 包均匀分布在 1 个解决方案中的 10 个项目中，那么每个文件将有不超过 100 个要跟踪的对象。我可以根据经验告诉您，我的 Reporting Services 项目的 RDL 文件比这多，而且只需几秒钟就可以在 BIDS 中正确加载解决方案。正如@revelator 所指出的，实际的SSIS 包是它们自己的单独的XML 文件。任何版本控制系统都应该将其中的每一个作为单独的文件进行跟踪，并且不会将它们组合成“一个巨大的 XML 文件”。如果您澄清这一点的意思，那么我认为您会在这个问题上得到更好的帮助。
无论您是运行一个包还是 1,000 个包，您都不会从 BIDS 以交互方式执行此操作。您可能会先将包部署到服务器，然后让服务器运行这些包。如果是这种情况，那么您可能需要使用 SQL Server 代理作业调用这些包。无论您是通过使每个包调用另一个包来链接包，还是通过让作业将每个包作为单独的作业步骤调用来链接包，您仍然可以通过日志记录跟踪您在链中的位置。如果您使用作业调用包，那么您也可以使用作业步骤对其进行跟踪。我运行一个包含许多包的数据仓库，我主要依赖于将进程分成多个作业，每个作业包含一个或多个包。我还使用启动作业命令链接作业，以便我可以更轻松地监控逻辑负载组的性能。此外，每个包都会在步骤级别的作业历史记录中显示其执行时间。此外，我在每个存储过程和包中都有自定义日志记录，显示单个数据加载或存储过程花费了多少秒和多少行，以便我可以解决性能瓶颈。
无论您做什么，都不要依赖以交互方式运行包来跟踪性能！在您的机器上运行 ETL 不会获得最佳性能，更不用说使用 GUI 运行它了。在服务器而不是桌面上的作业中运行包。交互式运行包只是为了帮助构建和排除单个包的故障，而不是管理日常 ETL。
如果您正在构建基于参数更改其目标和来源的通用包，那么您可能需要在数据库中构建一个控制表来跟踪进度。如果您只是将数据作为一次性事件从一个大型系统移动到另一个系统，那么您可能会将负载划分为一组小的程序包，并为每个程序包分配单独的作业，以便您可以更轻松地管理从故障中恢复。如果你打算构建一个定期运行的东西来移动数据，那么一个进程连续运行 2 天怎么可能有意义呢？听起来你的基础数据会在 2 天内发生变化......
如果您担心使用哪个版本控制系统来管理 SSIS 包项目，那么我可以说几乎任何都可以。我在不同的公司使用过 Visual SourceSafe 和 Perforce，它们在签入和签出单个软件包方面都具有相同的基本功能。我确信几乎任何与 Visual Studios 集成的版本控制系统都可以为您做到这一点。
希望您在上面找到有用的东西，并祝您的项目好运。
【讨论】：
版本控制使多人一起开发并从事同一个项目成为可能。如果我正在做某事，其他 ETL 开发人员将无法检查它并对其进行更改，直到我完成更改并将其重新检查。这解决了一个开发人员的项目工件和代码更改的常见情况无意中破坏了另一位开发人员。
http://blog.sqlauthority.com/2011/08/10/sql-server-who-needs-etl-version-control/
【讨论】：
我工作的大多数 ETL 项目都使用 SVN 作为源代码控制存储库。我发现的最佳方法是将每个项目或解决方案分解为更小、不同（通常可独立运行）的包。例如，假设您有一个名为 ManufacturingImport 的流程，这可能是您的项目。在此您将拥有一个 Master 包，然后根据需要调用其他包。这意味着团队成员可以处理不同的包或工作片段，而不是每个人都试图编辑同一个包并在合并时陷入麻烦。
【讨论】：