database - 使用 TFS 的数据库更改管理和构建过程

Question

有人使用 Team Foundation Server 来管理他们的数据库吗？我们目前正在使用颠覆。团队抱怨在 TFS 中创建构建过程很困难，并且正在回避它。

有什么好的建议、文章、经验吗？

Answer 1

数据库更改管理与您选择的版本控制系统没有太大关系，只要您首先拥有一个即可。当然，如果您使用的是 MS 的变更管理工具，您可以确定它们已经针对 TFS 和 MS 开发人员堆栈的其余部分进行了很好的测试。无论您使用 DBPro 还是经典 VS“数据库项目”或 SQL Management Studio 的精简项目/解决方案绑定中看到的更旧/更糟糕的集成形式，这都是正确的。但是没有理由不能将 DBPro 与 Subversion 一起使用，或者 Red Gate 与 TFS 一起使用。

构建生成也是如此。CC.NET vs Team Build、NAnt vs MSBuild 等等……官方的 MS 工具往往与竞争对手大致相当。您没有详细描述您的数据库部署过程，但我无法理解在 MSBuild 中编写脚本比您现在使用的脚本要困难得多（如果有的话）。在堆栈的不同点选择不同的工具集也不难：您可以让 CC.NET 驱动基于 MSBuild 的构建，这些构建使用 Red Gate 的命令行部署或任何其他组合。我碰巧认为坚持 MS 世界所提供的紧密集成远远超过任何一种工具的怪癖，但选择就在那里。

让我直奔主题：听起来您的主要问题不是技术问题，而是让 DBA 首先真正采用版本控制。如果您的“开发”和“产品”环境是它们自己的生命实体，而不是由某些可重复构建过程的结果专门定义的通用机器，那么在我的书中，您并没有真正使用版本控制。想象一下，如果客户端开发人员偶尔在公司周围的各种机器上手动调整 DLL，然后抱怨它们太难同步；你会认为他疯了。

除此之外，最重要的投资是到达一个从未直接对数据库做任何事情的地方（比你在 %programfiles% 中闲逛的更多）。如果它不在源存储库中，则它不存在。

我认为你如何到达那里并不重要。您可以在记事本中编写所有的 CREATE 和 ALTER，从命令行签入它们，然后让您的“构建过程”成为一个 2 行 shell 脚本，将它们连接到部署脚本知道要查找的众所周知的文件中. 或者你可以使用像 DBPro 这样的花哨工具来通过智能感知/单元测试/离线建模等来提高你的生产力。有充分的理由朝着后一个方向前进（特别是如果你认为声明式编程是一般要争取的东西），但我真的相信第一步是最大的。

Answer 2

我们将 Visual Studio 2008 Team Suite 与 TFS 一起使用。我能够相对轻松地将我们的数据库导入 TFS。但是，我发现大多数团队（包括 DBA）在修改 SQL 中的对象时忘记更新 TFS。

任何类型的构建过程都将依赖 DB Pro 在您的开发环境和目标环境之间生成差异脚本。我发现这是有问题的，因为我们的开发环境与我们的生产环境并不完全匹配。权限肯定是不同的，我们还有许多其他情况，其中更改已应用于 dev/QA 但从未移出到 prod（但也从未撤消）。尝试将您的更改与 DB Pro 中的许多其他更改隔离开来具有挑战性，因为 UI 使您从最终脚本中排除对象（因此，如果您修改 2 个对象而其他 1000 个对象不同，则必须取消选中其他 1000 个对象）。另外，schema比较的配置通常在tools->中完成

我认为该工具具有潜力，但我们当然需要调整我们现有的程序和系统以与 TFS 一起使用。此外，对数据库对象进行版本控制是非常宝贵的，即使它不是 100% 最新的。

Answer 3

我们将 TFS 与数据库版本一起使用。

数据库创建脚本具有将开发数据加载到数据库中的后置脚本。

我们定期部署到 DEV 环境。所有开发人员都在本地安装了 SQL，并且他们自己进行获取最新和部署。

在单元测试环境中，登录、数据库（OLTP 和 OLAP）、复制、ETL 包、SQL 作业等都部署到各自的位置，并且所有内容都已播种。

开发人员不会在外部进行任何更改，也不会将它们签入，因为这样部署到单元测试就不起作用了。

Answer 4

这个 Stack Overflow 问题对此有更多的看法： Visual Studio Team System Database Edition (GDR) 的真正好处是什么？ （我不知道为什么，但是我的搜索却让我想到了这个问题，而且我在寻找对此的意见时遇到了很多麻烦。希望这个链接能帮助其他人执行相同的搜索。）