与SSA、TFS和；出价

我目前是公司数据仓库和多维数据集的单一BI开发人员。我使用SQLServer2008、SSAS和SSIS作为基本工具包。我使用Visual Studio+BIDS和TFS进行IDE和源代码管理。我即将与一家海外供应商接手多个项目，我担心如何管理变化。我主要关心的是管理我和离岸团队之间的合并和变更。仅为一个人合并和管理对SQL&XML的更改已经够糟糕的了，但对于多个开发人员来说，这似乎是一场噩梦。在知道有时无法避免多个人对同一文件进行更改的情况下，您对如何最好地组织开发有何想法？

也许更好的标签是DVCS？

---

只要两个团队都在使用bids和TFS，这应该不是问题

假设您的tsql代码在每个对象的单个文件中签入到源代码管理中，合并tsql代码是直接的，因为它是基于文本的。我发现VSTS数据库项目对此有帮助

合并SSI和MSA的基于XML的源文件可能会很麻烦，如下所示。为了减轻一些痛苦，我发现将每个包限制在单个数据流或逻辑工作单元有助于减少开发人员对包的争用。然后我从一个或多个主包调用这些包。我还尝试使用存储过程、视图或UDF将所有tsql源查询外部化，以便进一步减少编辑包的需要。使用配置文件和变量在较小程度上也有帮助

---

MSSA立方体稍微坚硬一些。我的最佳建议是研究第三方xml差异化工具。我已经能够使用标准的基于文本的工具成功地合并小更改，但这可能是一项艰巨的任务。

SSI、SSAS和SSRS文件不适合合并。它们存储在一个xml文件中，该文件发生了巨大的变化——即使是很小的变化（例如更改属性）——因此合并变得非常不可能

所以不要再考虑在一个文件上进行并行开发。您需要考虑如何实现人们不需要在一个文件上进行并行开发。因此，从禁用文件的多次签出开始。您甚至可能想考虑启用选项以在结帐上获取最新版本。 然后开始思考如何让人们能够独立工作。这更多地体现在您构建作品和文件的方式上：

• 给人们提供他们自己可以工作的领域。一个SSIS包仅在任何给定时刻由person X开发
• 制作更小的文件，以便两个人在同一个文件中工作所需的更改较小

---

我已经向产品团队反馈了合并投标的不兼容性。这是一个众所周知的问题，但很难解决。他们不知道什么时候才能真正对这些文件进行并行开发。在此之前，请远离并行开发。

正如Ewald Hofman所提到的，SSA和SSI不利于合并

在一个工作环境中，我解决了以下问题：

• 仅在必要时使用SSI（模糊算法或类似的东西）。尽可能经常地用SQL代码替换SSIS包（例如，请参阅用于创建维度/事实表的datasync.和MEARGE命令）
• 按如下方式构建数据仓库结构：
• 构建两个数据库，一个用于源系统的“原始源数据”，另一个用于维度和事实视图及表的“阶段”数据库
• 使用可以部署整个“阶段”数据库的过程
• 将“stage”数据库的结构放入存储库中
• 构建一个C#应用程序，通过API构建您的维度和立方体（我知道，一开始这是一项艰巨的工作，但值得一试——想想您获得了什么——看看下面的优点）

• 将stage数据库和C#应用程序添加到存储库（TFS/Git等）

该结构的优点：

• 您有一个可合并的结构，可以放在存储库中
• 您正在使用的是AMO API
• 您可以自动生成新分区
• 您可以使用过程将度量值组自动化并克隆到不同的多维数据集（我认为这有时是一个很大的好处！）
• 你可以将你的翻译外包并轻松导入（立方体设计师可能不是最好的翻译）

欺骗：

• 供应商可能不会调整这种结构
• 你必须付更多的钱（因为更高的技能要求或是教他你的个人结构）
• 你可能需要一门新的C语言知识——如果你还没有

结论:

• 有可能获得一个合并友好的环境
• 您将失去良好的点击和运行工具f.e.投标-但将进入高自动化功能的过程
• 由于高度个性化，外包可能无利可图

---

TFS是我的雇主唯一允许使用的工具。切换到一个完全不同的源代码管理系统不是一个选项。抱歉，在重读了你原来的帖子之后，我理解你的问题更多的是关于合并，而不是关于如何对包和多维数据集进行源代码管理。我已经编辑了我的回复，希望您能发现它很有用。如果您认为合并SSIS包与任何其他类型的源代码没有什么不同，那么您就没有在团队环境中使用SSIS或大型XML文档。