是否有人使用Team Foundation Server来管理他们的数据库？我们目前正在使用颠覆。团队抱怨说很难在TFS中创建构建过程并且正在回避它。
有什么好的指针，文章，经验吗？
答案 0 :(得分：6)
数据库更改管理与您选择的版本控制系统没有多大关系，只要您首先拥有一个版本控制系统。当然，如果你使用的是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首先实际采用版本控制。如果你的“dev”和“prod”环境是他们自己的生物实体，而不是通过某些可重复的构建过程的结果完全定义的通用机器，那么你在我的书中并没有真正使用版本控制。想象一下，如果客户端开发人员偶尔在公司周围的各种机器上手动调整DLL，那么就会抱怨它们太难以同步;你以为他疯了。
除此之外，最重要的投资是进入一个没有直接对数据库做任何事情的地方（比你在％programfiles％中所做的更多）。如果它不在源存储库中，则它不存在。
我不认为你如何到达那里同样重要。你可以在记事本中编写所有的CREATE和ALTER，从命令行检查它们，并让你的“构建过程”成为一个2行的shell脚本，将它们连接成一个众所周知的文件，其中部署脚本知道看起来。或者您可以使用像DBPro这样的奇特工具，通过智能感知/单元测试/离线建模等来提高您的工作效率。有很好的理由可以向后一个方向前进（特别是如果您认为declarative programming需要努力的话。一般），但我真的相信第一步是最大的。
答案 1 :(得分：1)
我们正在使用Visual Studio 2008 Team Suite和TFS。我能够相对轻松地将我们的数据库导入TFS。但是，我发现大多数团队（包括DBA）在修改SQL中的对象时都忘记更新TFS。
任何类型的构建过程都将依赖于DB Pro在您的开发环境和目标环境之间生成差异脚本。我发现这是有问题的，因为我们的开发环境与我们的生产环境不完全匹配。权限肯定是不同的，我们还有许多其他情况，其中更改应用于dev / QA但从未移出prod（但也从未被撤销）。尝试将您的更改与DB Pro中的其他更改隔离开来具有挑战性，因为UI会使您从最终脚本中排除对象（因此，如果您修改了2个对象而其他1000个不同，则必须取消选中其他1000个对象）。此外，架构比较的配置通常在tools-＆gt;选项中完成，而其他工具（如Red Gate）允许您在启动它的同一屏幕上配置比较。
我认为该工具具有潜力，但我们当然需要调整现有的程序和系统以使用TFS。此外，对数据库对象进行版本控制是非常宝贵的，即使它不是最新的100％。
答案 2 :(得分：1)
我们将TFS与数据库版本一起使用。
数据库创建脚本具有将Dev数据加载到DB中的后期脚本。
我们定期部署到DEV环境。所有开发人员都在本地安装了SQL，他们自己创建了Get Latest和Deploy。
在单元测试环境中，登录，数据库（OLTP和OLAP），复制，ETL包，SQL作业等都部署到各自的位置，所有内容都是种子。
开发人员不在外面进行任何更改而不检查它们，因为部署到单元测试不起作用。
答案 3 :(得分：0)
在Stack Overflow问题中有更多的意见： What are the real benefits of Visual Studio Team System Database Edition (GDR)? （我不知道为什么，但我的搜索却把我带到了这个问题上，而且我在这方面遇到了很多麻烦。希望这个链接可以帮助其他人进行相同的搜索。）