Sri*_*ddi 4 database tfs tfsbuild
有人使用Team Foundation Server来管理他们的数据库吗？我们目前正在使用颠覆.团队抱怨说很难在TFS中创建构建过程并且正在回避它.
有什么好的指针,文章,经验吗？
数据库更改管理与您选择的版本控制系统没有多大关系,只要您拥有一个版本控制系统.当然,如果你使用的是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这样的奇特工具,通过智能感知/单元测试/离线建模等来提高您的工作效率.有很多理由可以向后一个方向发展(特别是如果您认为声明性编程是一般需要努力的话),但我真的相信第一步是最大的.