我公司提供面向.NET服务的大型解决方案。服务层与由数百个表和存储过程组成的T-SQL后端进行交互。我们的C＃代码在版本控制（SVN）中，但我们的存储过程和模式不是。
在对权宜之计高层管理人员进行大量游说之后，我被允许审查我们（不存在的）构建/部署过程以实现以下目标：
我想按照this post中接受的答案的策略继续进行，但还有其他问题：
我想使用Hudson作为构建服务器。这是C＃/ SQL解决方案的合理选择吗？我应该探索哪些更好的选择？
假设我在源代码管理下拥有所有触发器，存储过程，架构等，并且它们是编写到单个文件的脚本，我该如何生成一个构建脚本，该脚本将考虑依赖项/引用这些项目之间？ （SQL Server自动执行此操作，但它会生成一个巨大的脚本）
在客户端执行更新的工作流程是什么样的？即我必须保留现有的表格数据。如何回滚架构更改？
我是唯一的程序员。其他几位伪技术人员喜欢直接在SQL Management Studio中进行更改。期望他人遵守这个解决方案是否现实 - 我该如何强制执行？
提前感谢您的帮助。
编辑：
很遗憾，我们无法使用TFS。我们确实有可用的数据库项目组件的Visual Studio 2008/2010，所以看起来我不得不破解基于脚本的解决方案。任何建议/更新都表示赞赏..
答案 0 :(得分：4)
用于T-SQL部署的Microsoft堆栈的规范示例是Visual Studio数据库项目部署过程。在此过程中，您的数据库模式，过程，权限分配以及几乎所有其他内容都存储为VSDB项目的各个部分，这意味着它们存储为SQL定义文件，并在源代码管理下进行检查（SVN很好）。 “构建”过程提供.dbschema文件，该文件包含整个VSDB项目的综合（是一个美化的XML文件）。然后将.dbschema文件发送到部署服务器（开发服务器，QA验证服务器，甚至是生产服务器）和“已部署”。部署是通过vsdbcmd工具完成的，该工具将在部署服务器和.dbschema文件之间运行复杂的差异，并使用适当的CREATE / ALTER / DROP语句将服务器“对齐”到.dbschema文件的内容。 ，基于目标数据库/服务器中存在的内容。
一个连续集成的进程将启动每晚构建，将.dbschema与测试SQL服务器上的其他可交付项一起删除，部署.dbschema，然后运行构建验证测试，如果最终所有好处都将完全构建和QA验证可交付成果，即每日“下降”。可以完全集成到部署到生产中，但通常可以避免由于中央，生产，服务器意外停机的风险。但是，完全集成和部署到生产中通常是多服务器环境的标准，其中“生产”意味着数百/数千个已部署的服务器。
现在你说要使用Hudson进行部署，这一切都很好，除了你必须重新创建我在上面的步骤中描述的所有内容，因为Ants构建步骤，你将花费未来10年重新发明VS DB项目概念，如.dbschema文件和vsdbcmd之类的工具。我不是那个可以投资购买基于VSDB和TFS的构建服务器许可证的人，但我说我不知道OSS中提供的端到端解决方案。在VS 2010中，我相信数据库项目是标准版。使用VS 2008，您需要高端许可证。
用户通过SSMS进行射击更改：您可以使用DDL triggers阻止他们，您可以使用Event Notifications跟踪它们，或者您可以使用C2 compliant audit对其进行全面审核。