使用tfs[关闭]的数据库更改管理和生成过程

DB变更管理与您选择的版本控制系统没有太多关系,只要您首先有一个版本控制系统。当然,如果您使用的是来自MS的变更管理工具,那么您可以非常肯定它们已经在TFS和其他MS开发人员堆栈中得到了很好的测试。无论您是使用dbpro还是使用传统的vs“数据库项目”或SQL Management Studio简化的项目/解决方案绑定中的更老/更糟糕的集成形式,都是如此。但是你没有理由不能在Subversion中使用DBPro,或者在TFS中使用RedGate。

构建生成也是如此。CC.NET vs team build、nant vs ms build等……官方的MS工具往往与竞争对手大致持平。您没有详细描述您的DB部署过程,但我无法理解在msbuild中编写脚本比现在使用的脚本(如果有的话)要困难得多。在堆栈的不同点上选择不同的工具集也不难:您可以使用cc.net drive msbuild-based构建,这些构建使用Red Gate的命令行deploy或任何其他组合。我碰巧认为,坚持MS World所提供的紧密集成远远超过了任何一种工具的特性,但选择是存在的。

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

除此之外,最重要的投资是找到一个从未直接对数据库做过任何事情的地方(比你在%programfiles%中所做的更重要)。如果它不在源存储库中,那么它就不存在。

我不认为你是怎么到那里的。您可以在记事本中编写所有创建和更改,从命令行中签入它们,并让您的“构建过程”是一个2行shell脚本,将它们连接到一个部署脚本知道要查看的已知文件中。或者,您可以使用像dbpro这样的高级工具,通过intellisense/单元测试/离线建模等提高您的生产力。有很多理由朝后一个方向前进(尤其是如果您相信 declarative programming 总的来说是要努力的),但我真的相信第一步是最大的。

我们正在使用Visual Studio 2008团队套件和TFS。我可以相对轻松地将数据库导入到TFS中。但是,我发现大多数团队(包括DBA)在修改SQL中的对象时忘记更新TFS。

任何类型的构建过程都将依赖于DBPro在开发环境和目标环境之间生成差异脚本。我发现这有问题,因为我们的开发环境与我们的生产环境不完全匹配。权限当然是不同的,我们还有许多其他情况,其中在dev/qa中应用了更改,但从未移到prod(但也从未被逆转)。试图将您的更改与DBPro中的许多其他更改隔离开来是很有挑战性的,因为用户界面使您从最终脚本中排除对象(因此,如果您修改2个对象和1000个其他对象不同,则必须取消选中其他1000个对象)。此外,模式比较的配置通常在“工具”->选项中完成,而其他工具(如Red Gate)允许您在启动比较的同一屏幕上配置比较。

我认为这个工具有潜力,但我们当然需要调整现有的过程和系统来与TFS合作。此外,对数据库对象进行版本控制是非常宝贵的,即使它不是100%最新的。

我们在数据库版本中使用tfs。

数据库创建脚本具有将dev数据加载到数据库中的post脚本。

我们定期部署到开发环境中。所有开发人员都在本地安装了SQL,他们自己做的就是获取最新的SQL并进行部署。

在单元测试环境中,登录名、数据库(OLTP和OLAP)、复制、ETL包、SQL作业等都部署到各自的位置,并且所有内容都是种子。

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

在这个堆栈溢出问题中有更多的观点: What are the real benefits of Visual Studio Team System Database Edition (GDR)? (我不知道为什么,但我的搜索结果却让我想到了这个问题,我在这个问题上很难找到自己的观点。希望此链接可以帮助其他人执行相同的搜索。)